| Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
https://reviews.llvm.org/D148728 introduced `bool Sequential` to unify
`execute` and the old `spawn` without argument. However, sequential
tasks might be executed by any worker thread (non-deterministic),
leading to non-determinism output for ld.lld -z nocombreloc (see
https://reviews.llvm.org/D133003).
In addition, the extra member variables have overhead.
This sequential task has only been used for lld parallel relocation
scanning.
This patch restores the behavior before https://reviews.llvm.org/D148728 .
Fix #105958
Pull Request: https://github.com/llvm/llvm-project/pull/109084
|
|
|
|
Follow-up to d620ba0344c719da51b6067975439ed84024b1ac.
|
|
This member function is supposed to be private to MC. Also add an ifunc
test.
|
|
This builds the DAG from an ArrayRef of Instructions.
|
|
- **[Inliner] Add tests for incorrect propagation of return attrs; NFC**
- **[Inliner] Fix bug where attributes are propagated incorrectly**
The bug stems from the fact that we assume the new (inlined) callsite
is calling the same function as the original (callee) callsite. While
this is typically the case, since `VMap` simplifies the new
instructions, callee intrinsics callsites can end up not corresponding
with the same function.
This can lead to buggy propagation.
|
|
|
|
The new constructor creates an InstrInterval from an
ArrayRef<Instruction *>. This patch also adds top() and bottom()
getters.
|
|
This patch implements sandboxir::ConstantPtrAuth mirroring
llvm::ConstantPtrAuth
|
|
different ABIs, users and utilities. (#109338)"
This reverts commit 2e414799d0ad511cd7999895014a2cae2ea5e3e3.
Reason: buildbot breakage
(https://lab.llvm.org/buildbot/#/builders/51/builds/4105)
(This was the only new CL.)
/home/b/sanitizer-aarch64-linux/build/llvm-project/llvm/lib/Transforms/Coroutines/ABI.h:71:31: error: 'llvm::coro::AsyncABI' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
71 | class LLVM_LIBRARY_VISIBILITY AsyncABI : public BaseABI {
etc.
|
|
(#109416)
C++23 has stricter rules for forward declarations around
std::unique_ptr, this means that the inline declaration of the
constructor was failing under clang in C++23 mode, switching to an
out-of-line definition of the constructor fixes this.
This was fairly major impact as it blocked inclusion of a lot of headers
under clang in C++23 mode.
Fixes #106597.
|
|
users and utilities. (#109338)
* Adds an ABI object class hierarchy to implement the coroutine ABIs
(Switch, Asyc, and Retcon{Once})
* The ABI object improves the separation of the code related to users,
ABIs and utilities.
* No code changes are required by any existing users.
* Each ABI overrides delegate methods for initialization, building the
coroutine frame and splitting the coroutine, other methods may be added
later.
* CoroSplit invokes a generator lambda to instantiate the ABI object and
calls the ABI object to carry out its primary operations.
See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057
|
|
It's been more than five months since RawMemProfReader.h became a
"forwarding" header with:
commit 2bede6873dbe7021b306d3e5bec59d0fba2dd26c
Author: Kazu Hirata <kazu@google.com>
Date: Wed Apr 10 22:03:20 2024 -0700
This patch removes the empty header.
|
|
The uses of spirv-sim aren't gated by LLVM_INCLUDE_SPIRV_TOOLS_TESTS, so
the substitution shouldn't be gated either. Fixes tests after #107408
|
|
Change RegisterInfoEmitter to use const RecordKeeper.
This is a part of effort to have better const correctness in TableGen
backends:
https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
|
|
Remove dependency on VOPProfileI2F. This is to get ready for the
upcoming VOP3 true16 profile update. No test file changed.
|
|
|
|
|
|
Originally I tried spliting these features in the compiler with
https://github.com/llvm/llvm-project/pull/101712, but we decided to lump
those features in the ACLE specification (see
https://github.com/ARM-software/acle/pull/346). Since there are no
hardware implementations out there which implement ls64 without ls64_v
or ls64_accdata, this shouldn't be a regression for feature detection.
|
|
These are currently scalarized, and I need something to exercise
<N x i1> scalarization costing. We should probably consider adding
a buildvector intrinsic for this purpose.
|
|
Don't call raw_string_ostream::flush(), which is essentially a no-op.
As specified in the docs, raw_string_ostream is always unbuffered.
( 65b13610a5226b84889b923bae884ba395ad084d for further reference )
|
|
This change is actually two related changes, but they're very hard to
meaningfully separate as the second balances the first, and yet doesn't
do much good on it's own.
First, we can reduce the cost of a build_vector pattern. Our current
costing for this defers to generic insertelement costing which isn't
unreasonable, but also isn't correct. While inserting N elements
requires N-1 slides and N vmv.s.x, doing the full build_vector only
requires N vslide1down. (Note there are other cases that our build
vector lowering can do more cheaply, this is simply the easiest upper
bound which appears to be "good enough" for SLP costing purposes.)
Second, we need to tell SLP that calls don't preserve vector registers.
Without this, SLP will vectorize scalar code which performs e.g. 4 x
float @exp calls as two <2 x float> @exp intrinsic calls. Oddly, the
costing works out that this is in fact the optimal choice - except that
we don't actually have a <2 x float> @exp, and unroll during DAG. This
would be fine (or at least cost neutral) except that the libcall for the
scalar @exp blows all vector registers. So the net effect is we added a
bunch of spills that SLP had no idea about. Thankfully, AArch64 has a
similiar problem, and has taught SLP how to reason about spill cost once
the right TTI hook is implemented.
Now, for some implications...
The SLP solution for spill costing has some inaccuracies. In particular,
it basically just guesses whether a intrinsic will be lowered to a call
or not, and can be wrong in both directions. It also has no mechanism to
differentiate on calling convention.
This has the effect of making partial vectorization (i.e. starting in
scalar) more profitable. In practice, the major effect of this is to
make it more like SLP will vectorize part of a tree in an intersecting
forrest, and then vectorize the remaining tree once those uses have been
removed.
This has the effect of biasing us slightly away from strided, or indexed
loads during vectorization - because the scalar cost is more accurately
modeled, and these instructions look relevatively less profitable.
|
|
This reverts commit 98cf6560ab6df885b6e21463f6a0a1fa5cea1eea.
64972834c193 was reverted in 9c5ad62e7440
|
|
Support true16 and fake16 format for more VOP1 instructions in MC
This patch updates the true16 and fake16 vop_profile for the following
instructions and update the asm/dasm tests:
V_CVT_F16_U16
V_CVT_F16_I16
V_CVT_U16_F16
V_CVT_I16_F16
V_CVT_NORM_U16_F16
V_CVT_NORM_I16_F16
V_FREXP_EXP_I16_F16
Since this patch introduce fake16 instructions for V_CVT_F16_U16, it
address an issue in fix-sgprs-copy-f16 test which is brought up here
https://github.com/llvm/llvm-project/pull/104510#discussion_r1742499668
|
|
This patch fixes:
llvm/tools/llvm-c-test/debuginfo.c:254:20: error: unused variable
'AddDbgRecordLast' [-Werror,-Wunused-variable]
llvm/tools/llvm-c-test/debuginfo.c:257:20: error: unused variable
'AddDbgRecordOverTheRange' [-Werror,-Wunused-variable]
llvm/tools/llvm-c-test/debuginfo.c:264:20: error: unused variable
'AddDbgRecordUnderTheRange' [-Werror,-Wunused-variable]
|
|
In the test case, the BECount of the second loop uses %load,
but we only have an LCSSA phi node for %add, so that is what
gets invalidated. Use the forgetLcssaPhiWithNewPredecessor()
API instead, which will invalidate the roots of the expression
instead.
Fixes https://github.com/llvm/llvm-project/issues/109333.
|
|
Eliminate use of `convertInitializerTo` as that needs a non-const
RecordKeeper (which we want to make const).
|
|
getIntrinsicInstrCost() NFC. (#109379)
This patch fix the potential crash about using dyn_cast in `vp_cmp`
which is same as #109313.
Check if the IntrinsicCostAttrubute contains underlying instruction
first and cast to the VPCmpIntrinsic.
|
|
Update isDefinedOutsideLoopRegions to check if a recipe is defined
outside any region. Split off already approved
https://github.com/llvm/llvm-project/pull/95842 now that this can be
tested separately after landing VPlan-based LICM
https://github.com/llvm/llvm-project/issues/107501
|
|
This reverts commit 64972834c193632cbc47e54c0f0c721636b077e6.
Based on the discussions in #108991 that happened post merge, we have decided
to remove this pass in favor of generating `RISCV::G_*` opcodes in the legalizer.
We may reconsider moving that code elsewhere in the future so that we can do
a better job during generic combines. We don't feel that doing it in instruciton
selection is the right decision today. Firstly, it requires us to manually
do regbankselect on the newly introduced instructions. Secondly, it is more
difficult to test since the test output will contain whatever `RISCV::G_*`
instructions select to (instead of `RISCV::G_*`).
My personal opinion is that the legalizer pass can be split into an early
legalizer and a late legalizer, both before regbankselect. The first legalizer
would not introduce target specific generic opcodes and the generic combiner
would run after it. The second legalizer would introduce the target specific
generic opcodes. I think this approach is better than the lowerer because the
legalizer guarantees that whatever we lower to is legal, and apparently because
it is more performant at compared to the lowerer (although, I'm not sure how
true this is).
|
|
Since the migration from `@llvm.dbg.value` intrinsic to `#dbg_value`
records, there is no way to retrieve the debug records for an
`Instruction` in LLVM-C API.
Previously, with debug info intrinsics, retrieving debug info for an
`Instruction` could be done with `LLVMGetNextInstructions`, because the
intrinsic call was also an instruction.
However, to be able to retrieve debug info with the current LLVM, where
debug records are used, the `getDbgRecordRange()` iterator needs to be
exposed.
Add new functions for DbgRecord sequence traversal:
LLVMGetFirstDbgRecord
LLVMGetLastDbgRecord
LLVMGetNextDbgRecord
LLVMGetPreviousDbgRecord
See llvm/docs/RemoveDIsDebugInfo.md and release notes.
|
|
As discussed in [the
RFC](https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608)
we need a way to create labels in the assembler-generated line section
in order to support the future addition of the
[DW_AT_LLVM_stmt_sequence](https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434)
attribute.
We have a similar precedent for such behavior with the
[.cfi_label](https://github.com/llvm/llvm-project/pull/97922)
instruction - so we add the `.loc_label THE_LABEL_NAME` instruction
which:
- Terminates the current line sequence in the line section
- Creates a new label with the specified label name in the `.debug_line`
section
|
|
|
|
This is an almost-final step in eliminating debug-intrinsics -- read more
about that here: https://llvm.org/docs/RemoveDIsDebugInfo.html . To
correctly update variable location information in the background when
inserting instructions, we need some information carried at runtime in
BasicBlock::iterator, hence deprecating pointer-insertion.
An immediate fix for any deprecation warnings is to call "getIterator"
on the insertion position pointer. If you intend on inserting at the start
of a block, use BB->begin() or similar methods to fetch the appropriate
iterator.
|
|
This fixes a crash when svdiv's third parameter is svdup_s64(1)
|
|
|
|
|
|
|
|
We already infer this in IPSCCP (which runs very early, so cannot
benefit from inlining and simplifications) and SCCP (which runs without
PredicateInfo, so does not use assumes). Do it in CVP as well, so it can
handle cases that IPSCCP/SCCP can't.
Fixes https://github.com/llvm/llvm-project/issues/98946 (everything
apart from f2, where the assume is dropped by the frontend).
|
|
text (#107906)"
This reverts commit edf3b277a5f2ebe144827ed47463c22743cac5f9.
|
|
This reverts commit 3b3accb598ec87a6a30b0e18ded06071030bb78f.
|
|
This fixes:
```
[1832/3777] Building CXX object
lib\SandboxIR\CMakeFiles\LLVMSandboxIR.dir\SandboxIR.cpp.obj
In file included from
C:\src\git\llvm-project\llvm\lib\SandboxIR\SandboxIR.cpp:9:
C:\src\git\llvm-project\llvm\include\llvm/SandboxIR/SandboxIR.h(4400,16):
warning: unqualified friend declaration referring to type outside of the
nearest enclosing namespace is a Microsoft extension; add a nested name
specifier [-Wmicrosoft-unqualified-friend]
4400 | friend class TargetExtType; // For LLVMCtx.
| ^
| ::llvm::
1 warning generated.
```
|
|
Adopt `indent` for indentation DAGISelMatcher and DecoderEmitter.
|
|
Use const Record pointers in PredicateExpander.
This is a part of effort to have better const correctness in TableGen
backends:
https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
|
|
Change GISelCombinerEmitter to use const RecordKeeper.
This is a part of effort to have better const correctness in TableGen
backends:
https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
|
|
Change DisassemblerEmitter to use const RecordKeeper.
This is a part of effort to have better const correctness in TableGen
backends:
https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
|
|
Change AsmMatcherEmitter to use const RecordKeeper.
This is a part of effort to have better const correctness in TableGen
backends:
https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
|
|
Add initial transform to move out loop-invariant recipes.
This also helps to fix a divergence between legacy and VPlan-based cost
model due to legacy using ScalarEvolution::isLoopInvariant in some
cases.
Fixes https://github.com/llvm/llvm-project/issues/107501.
PR: https://github.com/llvm/llvm-project/pull/107894
|