This patch adds in documentation for the --use-dummy-perf-counters
option (introduced in D146301).
Reviewed By: kpdev42
Differential Revision: https://reviews.llvm.org/D147842
For a local pointer declaration of the form `T * p = 0` or `T * p = std::nullptr`,
Before this patch, we generate fix-its that convert the declaration to
`std::span<T> p{nullptr, <# placeholder #>}`, in cases where `p` is
used in some unsafe operations. This patch improves the fix-its to
result in a simpler form `std::span<T> p`. It gets rid of the
placeholder and keeps the result concise.
Reviewed by: NoQ (Artem Dergachev)
Differential Revision: https://reviews.llvm.org/D143680
Followup to D147354. Using src/conditions is discouraged in favor of using rules from the `@platforms` repository directly.
This replaces three conditions:
* `@bazel_tools//src/conditions:windows` -> `@platforms//os:windows`
* `@bazel_tools//src/conditions:darwin` -> `@platforms//os:macos`
* `@bazel_tools//src/conditions:freebsd` -> `@platforms//os:freebsd`
`llvm/config.bzl` has a non-trivial OS+CPU selection config, so that is omitted from this patch. There is intentionally no equivalent for that in `@platforms` because every project will have their own opinions about what a platform is, and it is not feasible for the bazel selection list to include every possible combination. The recommended idiom there is for projects to define their own supported platforms list, e.g. in a separate BUILD file or platform mapping.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D147948
We don't need to copy the ChildVariants vector into a new vector.
We're using std::move on every entry we copy so they clearly
aren't needed again. We can swap entries in the vector and reuse
it instead.
Summary:
This is to avoid using the callee saved registers for the return address
of the tail call return instruction.
Reviewers:
arsenm, cdevadas
Differential Revision:
https://reviews.llvm.org/D147096
Currently the driver does not propagate the `-f[no-]emulated-tls` flags
to the linker under LTO. This can be surprising when the platform
defaults differ from the flags being passed. A related discussion can be
found in https://reviews.llvm.org/D143619. While the focus there was
RISC-V support, the root cause was that setting `-femualted-tls` and
`-flto` when compiling with Clang resulted in missing symbols because
the platform defaults for Android differed from the flags being passed
to Clang.
This patch changes the Clang driver's behavior to pass the emulated-tls
flags through to the linker when compiling with LTO/ThinLTO.
Reviewed By: phosek, vit9696
Differential Revision: https://reviews.llvm.org/D147834
This file was added before we started granularizing the headers, but is essentially just a granularized header. This moves the header to the correct place.
Reviewed By: #libc, EricWF
Spies: libcxx-commits, arichardson, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146395
Implement SymbolFile::GetCompileOptions, which returns a map from
compilation units to compilation arguments associated with that unit.
Differential Revision: https://reviews.llvm.org/D147748
This patch fixes:
mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp:1334:51:
warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
lld/wasm/Writer.cpp:250:39: warning: suggest parentheses around ‘&&’
within ‘||’ [-Wparentheses]
This change adds a software implementation of the `math.ctlz` operation
and includes it in `--convert-math-to-funcs`.
This is my first change to MLIR, so please bear with me as I'm still learning
the idioms of the codebase.
The context for this change is that I have some larger scale project in which
I'd like to lower from a mix of MLIR dialects to CIRCT, but many of the CIRCT
passes don't support the `math` dialect.
I noticed the content of `convert-math-to-funcs` was limited entirely to
the `pow` functions, but otherwise provided the needed structure to implement
this feature with minimal changes.
Highlight of the changes:
- Add a dependence on the SCF dialect for this lower. I could have lowered
directly to cf, following the pow lowerings in the same pass, but I felt it
was not necessary given the existing support for lowering scf to cf.
- Generalize the DenseMap storing op implementations: modify the callback
function hashmap to be keyed by both OperationType (for me this effectively
means the name of the op being implemented in software) and the type
signature of the resulting function.
- Implement the ctlz function as a loop. I had researched a variety of
implementations that claimed to be more efficient (such as those based on a
de Bruijn sequence), but it seems to me that the simplest approach would make
it easier for later compiler optimizations to do a better (platform-aware)
job optimizing this than I could do by hand.
Questions I had for the reviewer:
- [edit: found mlir-cpu-runner and added two tests] What would I add to the filecheck invocation to actually run the resulting MLIR on a value and assert the output is correct? I have done this manually with the C implementation but I'm not confident my port to MLIR is correct.
- Should I add a test for a vectorized version of this lowering? I followed suit with the ` VecOpToScalarOp` but I admit I don't fully understand what it's doing.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D146261
Simplify the range reduction steps by choosing the reduction constants
carefully so that the reduced arguments v = r*m_x - 1 and v^2 are exact in double
precision, even without FMA instructions, and -2^-8 <= v < 2^-7. This allows the
polynomial evaluations to be parallelized more efficiently.
Reviewed By: santoshn, zimmermann6
Differential Revision: https://reviews.llvm.org/D147755
The ctype functions will sometimes be passed negative numbers, such as
EOF. Some of the previous implementations didn't handle these properly.
Additionally, the tests did not check any negative numbers. These
problems have been fixed.
This patch fixes https://github.com/llvm/llvm-project/issues/62000
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D147813
We set AddedComplexity = 100 for s_load patterns to prefer them over
global loads, but for s_buffer_load patterns there is no need to do
this and it was quietly overriding the AddedComplexity of each
individual GCNPat that is defined inside SMLoad_Pattern (but in practice
that did not appear to make any difference).
Differential Revision: https://reviews.llvm.org/D145396
The existing TOSA->Linalg lowering of tosa.gather only supports gathers
with either a static shape or a single dynamic batch dimension.
This change extends support to arbitrary number of dynamic dimensions on
both the values and indices of the gather operation.
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D147810
Extract the type converter definitions into its own .cpp
file so the type converter can be used by passes.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D147824
(and deduced return types)
Previously, only type constraints applied to type parameter
were semantically checked.
A diagnostic would still be emitted on instantiation, but it was
too late, lacked clarity, and was inconsistent with type parameters.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D147925
Some functions of asan depends on `Atexit()` handlers. On Windows, this
is implemented in ad3ec82bb1c7217b0187a1e16bb22642e194ce94 to queue the
handlers in a vector then register them with `atexit()` only after the
CRT is fully initialized. However, this is broken on MinGW with
asan_dynamic runtime due to different initialization order. This change
fixes the issue by making sure that `Atexit()` can call `atexit()`
directly past the pre-initialization phase.
This fixes two asan test cases on MinGW.
Differential Revision: https://reviews.llvm.org/D147413
Added option to ignore virtual methods in this check.
This allows to quickly get rid of big number of
potentialy false-positive issues without inserting
not-needed comments.
Fixes#55665.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D147918
Loop predication's predicateLoopExit pass does two incorrect things:
It sinks the widenable call into the loop, thereby converting an invariant condition to a variant one
It widens the widenable call at a branch thereby converting the branch into a loop-varying one.
The latter is problematic when the branch may have been loop-invariant
and prior optimizations (such as indvars) may have relied on this
fact, and updated the deopt state accordingly.
Now, when we widen this with a loop-varying condition, the deopt state
is no longer correct.
https://github.com/llvm/llvm-project/issues/61963 fixed.
Differential Revision: https://reviews.llvm.org/D147662
The single-argument constructors of this class were not marked explicit
and that led to some incorrect uses that slipped under the radar (see
changes in SemaDeclAttr.cpp). This makes the constructors explicit,
changes the benignly incorrect uses, and updates the tablegen code to
emit the correct support code to call the explicit constructors.
While this does correct a misuse, that incorrect usage could not be
observed except via a debugger and so no additional tests are added.
Differential Revision: https://reviews.llvm.org/D147661
Instead of iterating over all LCSSA phis in the exit block, collect all
LiveOut users of the FOR splice VPInstruction and only update those
users.
Building on top of D147471, this removes an access to the cost model
after VPlan execution.
Depends on D147471.
Reviewed By: Ayal, michaelmaitland
Differential Revision: https://reviews.llvm.org/D147472
Refactor the Namespaces with NamespaceDecl[][].
First level stores non nested namepsace.
Second level stores nested namespace.
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D147893
[[https://wg21.link/p1787 | P1787]]: CWG536 (long partially resolved) is resolved by specifying that unqualified lookup occurs for any kind of unqualified-id as an id-expression.
Wording: An unqualified name is a name that <...>. Unless otherwise specified, such a name undergoes unqualified name lookup from the point where it appears. ([basic.lookup.unqual]/4)
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D147564
Apply loop guards to AddRec's start in range computation for
non-self-wrapping AddRecs.
According to CT measurements, this has a wide negative compile time impact,
so we hold it in expensive range sharpening mode where it's not so critical.
However, we need to find a way to share benefits of this mode with default mode.
Patch by Aleksandr Popov!
Differential Revision: https://reviews.llvm.org/D147557
Reviewed By: mkazantsev
Previously we were passing 'this' and the std::shared_ptr version
of 'this'. This replaces all uses of 'this' with the shared_ptr and
makes the method static.
It is not actually used for any computations. Its only purpose is to
check that the loop is finite and find out the type of computed exit
count. Refactor code so that we only store this type.
`unpckps` has the same performance as `unpckpd` (only port5) wereas
`unpckdq` can run on p15 on some newer architectures.
`unpckdq` is in the integer domain, so only do the transform if the
target has no bypass delay on shuffles (SKL+).
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D147729
`unpckqdq` seems to be treated as a shuffle from bypass delay
perspective (which makes sense it appears to have shared shuffle units
for all micro-arch).
`unpckqdq` is slightly preferable to `shufpd` as it saves 1-byte of
code size and can be used to replace the micro-fused `rm` version. So,
if the target has no bypass delay, we should do `unpckpd` ->
`unpckqdq` instead of `shufpd.
Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D147728
We shouldn't do the transformation if we either have bypass delay OR
the new opcode has worse performance. Previous code was incorrectly
using AND.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D147727
1) Add tests for `unpckps`.
2) Add explicit test for fast shuffles (ICX+) but WITH bypass delay.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D147726
