[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>
net/wol: add access to get_arp so dashboard widget works
For core the dashboard ACL holds all the dashboard related API
patterns but we don't want to taint it with plugin requirements.
So instead of adding a WoL-Dashboard privilege add the required
API endpoint to the standard ACL to unbreak. This is only relevant
for the plugin when installed and explicitly using the privilege.
[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
