[mlir][tosa] Add concat_shape Op folder (#183293)
Apply compile time folding for TOSA.CONCAT_SHAPE
---------
Signed-off-by: Udaya Ranga <udaya.ranga at arm.com>
[clang] Expose normalized module cache path in `HeaderSearch` (#185746)
Previously, the normalized module cache path was only accessible via
`HeaderSearch::getSpecificModuleCachePath()` which may or may not also
contain the context hash. Clients would need to parse the result to
learn the normalized module cache path. What `ASTWriter` does instead is
normalize the as-written module cache path redundantly.
Instead, this PR exposes the normalized module cache path in the
`HeaderSearch` interface and moves the computation of specific module
cache path into the clangLex library.
This is motivated by another patch that would've needed to redundantly
perform the module cache path canonicalization or parse the specific
module cache path.
[clang][ssaf] Add LUSummary consumer APIs
This patch adds the consumer-side infrastructure for the Scalable Static
Analysis Framework (SSAF). After the EntityLinker produces a LUSummary,
these new components build typed analysis data from it.
- `SummaryData` — A base class for analysis views to expose
analysis-specific query API.
- `SummaryDataBuilder` — An abstract base class that populates a
concrete `SummaryData`.
- `SummaryDataBuilderRegistry` — A registry wrapper for
`SummaryDataBuilder` class.
- `SummaryDataStore` - A wrapper containing a map from `SummaryName` to
`SummaryData`, returned as a result of running the `LUSummaryConsumer`.
- `LUSummaryConsumer` — Drives the process of populating `SummaryData`
instances from `LUSummary` via corresponding `SummaryDataBuilder`
instances.
[MCP] Never eliminate frame-setup/destroy instructions
Presumably targets only insert frame instructions which are significant,
and there may be effects MCP doesn't model. Similar to reserved registers this
is probably overly conservative, but as this causes no codegen change in
any lit test I think it is benign.
The motivation is just to clean up #183149 for AMDGPU, as we can spill
to physical registers, and currently have to spill the EXEC mask purely
to enable debug-info.
Change-Id: I9ea4a09b34464c43322edd2900361bf635efd9f7
[MCP][NFC] Opinionated refactoring using new type
There are a few minor inconsistencies across the pass which I found mildly
distracting:
* The use of `Def`/`Dest`/`Dst` to refer to the same thing
* Inconsistent declaration order of `Def`/`Src` vs `Src`/`Def`
* Lots of `->getReg()->asMCReg()`, and uses of `Register` when the pass
is always running after RA anyway.
* Some places explicitly `assert(isCopyInstr)` while others just deref
the `optional`.
The refactor uses structured bindings for a couple reasons:
* Naturally enforces consistent order of `Def`-then-`Src`
* Requires the use of `auto`, which ensures the declaration is not
implicitly converting from `MCRegister` back to `Register`.
In both cases the explicitness of the name `getDefSrcMCRegs` hopefully
[9 lines not shown]
[MCP] Never eliminate frame-setup/destroy instructions
Presumably targets only insert frame instructions which are significant,
and there may be effects MCP doesn't model. Similar to reserved registers this
is probably overly conservative, but as this causes no codegen change in
any lit test I think it is benign.
The motivation is just to clean up #183149 for AMDGPU, as we can spill
to physical registers, and currently have to spill the EXEC mask purely
to enable debug-info.
Change-Id: I9ea4a09b34464c43322edd2900361bf635efd9f7
[MPC][NFC] Opinionated refactoring using new type
There are a few minor inconsistencies across the pass which I found mildly
distracting:
* The use of `Def`/`Dest`/`Dst` to refer to the same thing
* Inconsistent declaration order of `Def`/`Src` vs `Src`/`Def`
* Lots of `->getReg()->asMCReg()`, and uses of `Register` when the pass
is always running after RA anyway.
* Some places explicitly `assert(isCopyInstr)` while others just deref
the `optional`.
The refactor uses structured bindings for a couple reasons:
* Naturally enforces consistent order of `Def`-then-`Src`
* Requires the use of `auto`, which ensures the declaration is not
implicitly converting from `MCRegister` back to `Register`.
In both cases the explicitness of the name `getDefSrcMCRegs` hopefully
[9 lines not shown]
[MCP][NFC] Cleanup and prepare to preserve frame-setup/destroy
This mixes renames, removing redundant code, avoiding
`else`-after-`return`, etc. with factoring out the `isNeverRedundant`
concept. I can drop any bits people would rather I not touch.
Change-Id: I43a62a9415019cdd63c68fd3b915ebb7505d317a
[CodeGen][MC][NFC] Clarify MCRegister ctor behavior
This is something I have learned, forgotten, and relearned
at least once now, so I figured it is worth noting in a comment:
the `MCRegister` constructor does not `assert` on non-Physical,
non-Invalid values.
Also do some related cleanup:
Make `MCRegister::from` be `constexpr` and use it in `Register::asMCReg`
instead of duplicating the `assert`.
Reword the doc-comment on `MCRegister::from` to avoid using the
overloaded term "valid" (an "invalid" `MCRegister` is perfectly valid here).
Change-Id: I0985a825ae83d0601899fa4ab046ff262359e93f
[NFC][sancov] Move tests into target-specific subdirectories (#182111)
Move tests into target-specific subdirectories:
- `X86/` - tests that use x86 binaries
- `AArch64/` - tests that use AArch64 binaries
Each subdirectory has its own `lit.local.cfg` with the appropriate
target requirement.
---------
Co-authored-by: Honey Goyal <honey.goyal3 at ibm.com>
[sanitizer-coverage] clean up unused test (#186147)
Since commit 53b34c844339 ("[sanitizer-coverage] remove stale code (old
coverage); llvm part"), which landed in 2017, the CHECK0, CHECK1,
CHECK_WITH_CHECK, CHECK2, and CHECK3 lines don't get checked by anything
anymore. That's confusing, get rid of them.
Also tweak the CHECK_TRACE_PC test to verify that edge coverage actually
covers the entry point and the two control flow edges in the input;
CHECK3 used to do similar checks.
[clang][ssaf] Rename `ssaf-format` tool to `clang-ssaf-format`
This patch renames the `ssaf-format` tool to `clang-ssaf-format` to
decrease the chance of conflicts with binaries from other projects. This
issue was brought up in
https://github.com/llvm/llvm-project/pull/184713#issuecomment-4030747461
