A few additions:
- Lines with `{{`: These can show up if serializing non-MLIR info into
string attrs `my.attr = {{proto}, {...}}`. String escape the opening
`{{`, given that check lines are generated this has no effect on
`{{.*}}` etc in generated lines.
- File split line: Normally these are skipped because of their indent
level, but if using `--starts_from_scope=0` to generate checks for the
`module {...} {` line, and since MLIR opt tools emit file split lines by
default, some `CHECK: // -----` lines were emit.
- (edit removed this, fixed by
https://github.com/llvm/llvm-project/pull/134364) AttrAliases: I'm not
sure if I'm missing something for the attribute parser to work
correctly, but I was getting many `#[[?]]` for all dialect attrs. Only
use the attr aliasing if there's a match.
The calleeDecl var will be used in the near future, so I left it. At
least for clang, the [[maybe_unused]] attribute takes care of the
warnings related to that variable. The other warning was a simple lack
of return after errorNYI.
This patch adds `VisitBinAssign` and `VisitBinComma` to the ClangIR
`ScalarExprEmitter` to enable assignments and the comma operator.
---------
Co-authored-by: Morris Hafner <mhafner@nvidia.com>
`Sema::getCurFunctionDecl(AllowLambda = false)` returns a nullptr when
the lambda declaration is outside a function (for example, when
assigning a lambda to a static constexpr variable).
This triggered an assertion in
`SemaAMDGPU::CheckAMDGCNBuiltinFunctionCall`.
Using `Sema::getCurFunctionDecl(AllowLambda = true)` returns the
declaration of the enclosing lambda.
Stumbled with this issue when refactoring some code in CK.
Fixes the case where subsequent passes were unable to find and delete
the invariant loop left over by the strlen idiom conversion. Since
`loop-deletion` only operate on computable loops, we can update the loop
condition to something more easily picked up by `loop-deletion`
As pointed out in https://github.com/llvm/llvm-project/issues/134736
This PR extracts the creation of `CompilerInstance` for compiling an
implicitly-discovered module out of `compileModuleImpl()` into its own
separate function and passes it into `compileModuleImpl()` from the
outside. This makes the instance creation logic reusable (useful for my
experiments) and also simplifies the API, removing the `PreBuildStep`
and `PostBuildStep` hooks from `compileModuleImpl()`.
Eliminate the potential for a race between the main thread, the default
event handler thread and the signal handling thread, when accessing the
m_statusline member.
Static analysis flagged 1 - ArgIdx in Sema::AddOverloadCandidate for its
potential to overflow.
Turns out this is intentional since when PO ==
OverloadCandidateParamOrder::Reversed Args.size() is always two, so this
will never overflow.
We document using an assert.
Fixes: https://github.com/llvm/llvm-project/issues/135086
With implicitly-built modules, seeing something like:
```
fatal error: module 'X' is defined in both '<cache>/HASH1/X-HASH2.pcm' and '<cache>/HASH1/X-HASH3.pcm'
```
is super confusing and not actionable, because the module cache tends to
be hidden from the developer.
This PR adds a note to that diagnostic that names the module map files
the PCM files were compiled from, hopefully giving a good enough hint
for further investigation:
```
note: compiled from '<build>/X.framework/Modules/module.modulemap' and '<SDK>/X.framework/Modules/module.modulemap'
```
(I had to replace the mechanism used to convert `DiagnosticError` into
something `DiagnosticsEngine` can understand, because it seemingly did
not support notes.)
This PR is after #135253 and #134935 to fix the error reported by
https://github.com/llvm/llvm-project/pull/135253#issuecomment-2796077024.
This PR Adds typedef declarations for `MlirLinalgContractionDimensions`
and `MlirLinalgConvolutionDimensions` in the C API to ensure
compatibility with pure C code.
I confirm that this fix resolves the reported error based on my testing.
Signed-off-by: Bangtian Liu <liubangtian@gmail.com>
The Apple runners automatically pick up newer XCode versions breaking
the CI. This disables the test to get the CI green which allows us to
investigate the issue properly later on.
Stop just replacing 2*UNPCK+INSERT_SUBVECTOR with 2*INSERT_SUBVECTOR+UNPCK
Currently limited to sub-64-bit element cases until we've accounted for the remaining regressions from some build_vector style patterns.
Commit c2e62c7 updated the ReduceDIMetadata pass to be able to remove
DIGlobalVariableExpressions from MDNode operands; it also accidentally
prevented null operands from being preserved, which results in an
assertion being triggered:
`Targets == NoChunksCounter.count() && "number of chunks changes when
reducing"'
This patch allows us to correctly preserve null operands once again.
I've not got a test case for this yet - I'm hoping this patch is just
trivially correct as-is, because I've not got the hang of reducing a
test case for llvm-reduce yet, but I can get a test case generated if
needed.
- Remove pass initialization calls from pass constructors.
- Move pass initialization and creation function declarations to
Hexagon.h and remove them from individual .cpp files.
- Add calls for pass initialization in Hexagon target initialization.
- https://github.com/llvm/llvm-project/issues/111767
Add additional cases of this canonicalization, by checking the 'source
of truth' function `isBroadcastableTo` to check when it is possible to
broadcast directly to the shape resulting from the shape_cast.
---------
Signed-off-by: James Newling <james.newling@gmail.com>
On ARM64EC, the `IMAGE_SCN_GPREL` flag is repurposed to indicate that
section code is x86_64. This enables embedding x86_64 code within
ARM64EC object files. MSVC uses this for export thunks in .exp files.
Based on the ShapeCastConstantFolder, this pattern replaces
%0 = ub.poison : vector<2x3xf32>
%1 = vector.shape_cast %0 vector<2x3xf32> to vector<6xf32>
with
%1 = ub.poison : vector<6xf32>
---------
Signed-off-by: James Newling <james.newling@gmail.com>
Currently rocm-device-lib-path is not enabled for Flang, so when the
compiler warns / requests a user to provide this option in cases where
it can't find rocm a user cannot actually set the device libraries using
rocm-device-lib-path. The alternative rocm_path that's also mentioned
via the warning can be used, but we should enable both mentioned options
to not confuse users (and myself).
Originally, the intent behind symtab was to represent the symbol table
seen in the PE header (without applying ARM64X relocations). However, in
most cases outside of `writeHeader()`, the code references either both
symbol tables or only the EC one, for example, `mainSymtab` in
`linkerMain()` maps to `hybridSymtab` on ARM64X.
MSVC's link.exe allows pure ARM64EC images to include native ARM64
files. This patch prepares LLD to support the same, which will require
`hybridSymtab` to be available even for ARM64EC. At that point,
`writeHeader()` will need to use the EC symbol table, and the original
reasoning for keeping it in `hybridSymtab` no longer applies.
Given this, it seems cleaner to treat the EC symbol table as the “main”
one, assigning it to `symtab`, and use `hybridSymtab` for the native
symbol table instead. Since `writeHeader()` will need to be conditional
anyway, this change simplifies the rest of the code by allowing other
parts to consistently treat `ctx.symtab` as the main symbol table.
As a further simplification, this also allows us to eliminate `symtabEC`
and use `symtab` directly; I’ll submit that as a separate PR.
The map file now uses the EC symbol table for printed entry points and
exports, matching MSVC behavior.
If the buildvector node contains constants and non-constants, need to
consider shuffling of the constant vec and insertion of unique elements
into the vector. Also, if there is an input vector, need to consider the
cost of shuffling source vector and constant vector and then insertion
and shuffling of the non-constant elements.
Reviewers: hiraditya, RKSimon
Reviewed By: RKSimon
Pull Request: https://github.com/llvm/llvm-project/pull/135245
This reverts commit d1156fcb56891fb1a426c3e8331a51d47f98a1b8.
This patch fixes the reported incorrect formatting changes and adds
tests for them. The performance should be unaffected, since there are no
significant changes required to fix the bugs.
Specifically, a `>` was changed to a `>=` to also add a `+` in the zero
case, and we're checking for zero now before printing the octal and
hexadecimal prefixes.
Closes#131710
This PR accounts for scaled reductions in `calculateRegisterUsage` to
reflect the fact that the number of lanes in their output is smaller
than the VF.
Depends on https://github.com/llvm/llvm-project/pull/126437
Original in https://github.com/llvm/llvm-project/pull/134626 was
written as if it was "this or this" but it's "this and this".
So the test ran on AArch64 Linux, because Linux is not Windows.
Split out the Windows check to fix that.
Ops that are already snake case (like [`ROCDL_wmma_*`
ops](66b0b0466b/mlir/include/mlir/Dialect/LLVMIR/ROCDLOps.td (L411)))
produce python "value-builders" that collide with the class names:
```python
class wmma_bf16_16x16x16_bf16(_ods_ir.OpView):
OPERATION_NAME = "rocdl.wmma.bf16.16x16x16.bf16"
...
def wmma_bf16_16x16x16_bf16(res, args, *, loc=None, ip=None) -> _ods_ir.Value:
return wmma_bf16_16x16x16_bf16(res=res, args=args, loc=loc, ip=ip).result
```
and thus cannot be emitted (because of recursive self-calls).
This PR fixes that by affixing `_` to the value builder names.
I would've preferred to just rename the ops but that would be a breaking
change 🤷.
When you call the `SBTarget::ReadInstructions` with flavor from lldb
crashes. This is because the wrong order of the `DisassemblyBytes`
constructor this fixes that
---------
Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
One was "unsafe use of bool" and the other was "sign comparision
mismatch", and both were because we're treating a bool object as if it
were an unsigned int. Add a cast to make that more explicit.
