Fix: `!$acc declare present(/COMMON/)` no longer adds
`acc.declare(dataClause=acc_present)` attribute to the fir.global
common.
Lowering change: COMMON+present is lowered through the structured
declare path (fir.address_of + acc.present operand) to preserve scope.
Frequently, when big buffers are put on the stack we end up
with multiple virtual pages Copy-On-Write mapped to single physical zero page.
Stack probes would unnecessarily trigger a Copy-On-Write on such pages. Avoid this
by using loads into the XZR.
Removed unused functions in order to fix 'unused function' warnings, as
mentioned in PR 171889. This involved the two original functions
```ControlConditions::isEquivalent(const ControlConditions &Other)
const``` and ```ControlConditions::collectControlConditions(const
llvm::BasicBlock&, const llvm::BasicBlock&, const llvm::DominatorTree&,
const llvm::PostDominatorTree&, unsigned int)``` plus all the functions
that became unused as the result of deleting the two original ones.
Co-authored-by: Szymon Sobieszek <szymon.sobieszek1@huawei.com>
The way HwMode is currently implemented, tablegen duplicates each
pattern that is dependent on hardware mode. The HwMode predicate is
added as a pattern predicate on the duplicated pattern.
RISC-V uses HwMode on the GPR register class which means almost every
isel pattern is affected by HwMode. This results in the isel table
being nearly twice the size it would be if we only had a single GPR
size.
This patch proposes to do the expansion at instruction selection time
instead. To accomplish this new opcodes like OPC_CheckTypeByHwMode
are added to the isel table. The unique combinations of types and HwMode
are converted to an index that is the payload for the new opcodes.
TableGen emits a new virtual function getValueTypeByHwMode that uses
this index and the current HwMode to look up the type.
This reduces the size of the isel table on RISC-V from ~2.38 million
bytes to ~1.38 million bytes.
I did not add an OPC_SwitchTypeByHwMode opcode yet. If the VT requires a
hardware mode, we emit an OPC_Scope+OPC_CheckTypeByHwMode instead. I
expect adding an OPC_SwitchTypeByHwMode could further reduce the table
size. I will investigate this as a follow up.
Many of the matcher classes in tablegen now use ValueTypeByHwMode
insteadof MVT. This may have an impact on the memory usage and runtime of
tablegen. We can mitigate some of this by splitting the matchers into MVT and
ValueTypeByHwMode versions. We can also explore alternate data
structures for ValueTypeByHwMode instead of a std::map. Maybe a sorted vector.
A similar change can be made to GlobalISel as a follow up.
This PR updates the `CHANGE TEAM` construct to fix the bug mentioned in
the issue #171048.
When a construct such as `IfConstruct` was present in the `CHANGE TEAM`
region, several BB were created but outside the region.
For ThinLTO we only have the cloning information in the FunctionSummary,
so for aliases we create as many clones as there are aliasee clones in
the LTO backend. However, that information is only in the prevailing
symbol's summary, as we don't keep the memprof summary information for
other copies (to reduce memory and compile time).
In the case of weak aliases, it is possible that the prevailing copy
of the alias may be in a different module than the prevailing copy of
the aliasee (e.g. when a module with a weak_odr aliasee definition does
not have a def of the weak_odr alias and is listed first on the link
line). In that case, we were not creating the expected clones of the
alias.
Rather than a more complex solution that adds additional summary
information, detect this case and simply don't add the callsites in the
aliasee function to the callsite context graph. This will result in
conservativeness (because we can't clone through that function), but
this should be a corner case.
This patch migrates the intrinsic properties back to "PureIntrinsic"
from "NVVMPureIntrinsic" (after PR #166450).
While we are there:
* Refactor a few mbarrier intrinsics definitions (NFC)
* Update mbarrier.pending_count properties. (trivial)
* Formatting changes over a few fence intrinsics (NFC)
This was causing failures in the release branch as the premerge jobs
there are also run postcommit through GHA. We were expecting a PR number
to always be present when it was not.
In XeGPUPropagateLayout.cpp, the helper getDefaultSIMTLayoutInfo is
implemented via multiple overloads that differ significantly in
semantics, not just parameter types.
Reusing the same function name for these semantically different
behaviors makes call sites harder to read and reason about and increases
the maintenance burden. This PR improves readability and maintainability
of layout propagation logic.
In the profcheck build, FileCheck commands are substituted with cat > /dev/null to disable output verification. In test/Transforms/SamplePrfile/remarks-hotness.ll we have both "FileCheck"
and "not FileCheck" statements. Replacing the positive one first results in "not cat".
Run the not substitution first to fix this.
Rename the `gc-empty-basic-blocks` command line option to
`enable-gc-empty-basic-blocks` in preparation of adding calls to
initializing the pass in `initializeCodeGen` and also make the flag more
consistent with other existing flags to enable or disable passes.
Keep `gc-empty-basic-blocks` as an alias to allow all users to migrate
to the new option.
MSVC versions prior to 19.43 (Visual Studio 2022 version 17.13) emit a
warning when using the [[msvc::no_unique_address]] attribute prior to
C++20.
This is now considered a bug and fixed in later releases of MSVC.
Suppress the warning for older MSVC versions by disabling the warning
around the attribute usage. This allows for warning-free builds when
targeting older MSVC versions.
More details and discussion about the warning can be found here:
https://developercommunity.visualstudio.com/t/msvc::no_unique_address-Should-Not-W/10118435
Reverts llvm/llvm-project#176091
Reverting because some compilers were erroring on the call to
`Reg.isReg()` (which is not `constexpr`) in a `constexpr` function.
This Change is to prepare to make RegState into an enum class. It:
- Updates documentation to match the order in the code.
- Brings the `get<>RegState` functions together and makes them
`constexpr`.
- Adopts the `get<>RegState` where RegStates were being chosen with
ternary operators in backend code.
- Introduces `hasRegState` to make querying RegState easier once it is
an enum class.
- Adopts `hasRegState` where equivalent was done with bitwise
arithmetic.
- Introduces `RegState::NoFlags`, which will be used for the lack of
flags.
- Documents that `0x1` is a reserved flag value used to detect if
someone is passing `true` instead of flags (due to implicit bool to
unsigned conversions).
- Updates two calls to `MachineInstrBuilder::addReg` which were passing
`false` to the flags operand, to no longer pass a value.
- Documents that `getRegState` seems to have forgotten a call to
`getEarlyClobberRegState`.
Add CFG-based lifetime analysis tests for dangling pointer detection
alongside the existing AST-based analysis.
This change helps validate that the new CFG-based lifetime analysis
correctly detects the same dangling pointer issues as the existing
AST-based analysis. It also documents current limitations of the
CFG-based approach with FIXME comments, providing a roadmap for future
improvements. The test ensures that both analysis methods can work
side-by-side, with the CFG-based analysis eventually intended to replace
the AST-based approach.
Entry value operations could previously not be combined with other
operations in debug expressions, meaning that we had to skip emitting
call site values in such cases. This DIExpression limitation was removed
in 57a371d7010802804343d17b85ac5e0d28d0f309, so we should be free to
emit call site values for such cases now, for example:
extern void call(int, int);
void entry_value (int param) {
call(param + 222, param - 444);
}
This change exposed a call site parameter entry order issue in the
dbgcall-site-expr-entry-value.mir test case. That ordering issue is
tracked in #43998, and I don't think there is anything inherent in this
patch that caused that.
This patch adds support for scalarizing vector loads in the legalizer
and
implements legalization for the spv_const_composite intrinsic. It also
refactors stack temporary creation for vector operations to ensure
correct
SPIR-V types are assigned. Additionally, type deduction in the
PostLegalizer is improved to handle GEP and Load instructions.
Fixes https://github.com/llvm/llvm-project/issues/170534
This makes it clear the fields required for attaching to an existing
debug session.
It also makes it easier to check mutually exclusive fields required to
attach.
While it is correct to assign a single fixed hash to all template
arguments, it can reduce the effectiveness of lazy loading and is
not actually needed: we are allowed to ignore parts that cannot be
handled because they will be analogously ignored by all hashings.
Reviewed as part of https://github.com/llvm/llvm-project/pull/133057
If the the node to throttle is a vector node, which is used in split
node, and at least one scalar of such a node is used in many split
nodes, such vector node should be throttled. otherise there might be
wrong def-use chain, which crashes the compiler.
Fixes#175967
Currently running llvm-readobj --all on any MachO object asserts,
because it implies --offload, and the --offload extraction includes an
assert on the object format. Instead, we should be silently ignoring.
This regressed in https://github.com/llvm/llvm-project/pull/143342.
This avoids implicit truncation assertions with
https://github.com/llvm/llvm-project/pull/171456. Apparently the
alignment code path was previously untested.
The first commit switches the test to generated check lines.
