#
3257f63b |
| 23-Nov-2021 |
David Sherwood <david.sherwood@arm.com> |
[NFC][CodeGen] Remove rarely used DL variable from SelectionDAGBuilder
There is a pointer to the DataLayout in SelectionDAGBuilder called 'DL' that is hardly ever used. In most cases the code seems
[NFC][CodeGen] Remove rarely used DL variable from SelectionDAGBuilder
There is a pointer to the DataLayout in SelectionDAGBuilder called 'DL' that is hardly ever used. In most cases the code seems to just use `DAG.getDataLayout()` instead. Given that DL is also often used as a shadowed variable for the debug location it seems sensible to just kill off the few remaining uses and be consistent with the rest of the code.
Differential Revision: https://reviews.llvm.org/D114451
show more ...
|
#
630c847b |
| 07-Dec-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Use range-based for loops (NFC)
|
#
40d51de5 |
| 03-Dec-2021 |
Fraser Cormack <fraser@codeplay.com> |
[SelectionDAG] Use UnknownSize for VP memory ops
In the style of D113888, this patch updates the various VP memory operations (load, store, gather, scatter) to use UnknownSize. This is for the same
[SelectionDAG] Use UnknownSize for VP memory ops
In the style of D113888, this patch updates the various VP memory operations (load, store, gather, scatter) to use UnknownSize. This is for the same reason as for masked loads and stores: the number of elements accessed is not generally known at compile time.
This is somewhat pessimistic in the sense that we may still find un-canonicalized intrinsics featuring both an all-true mask and an EVL equal to the vector size. Arguably those should be canonicalized before the SelectionDAG, so those have been left for future work.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D115036
show more ...
|
#
3460cc25 |
| 19-Nov-2021 |
Fraser Cormack <fraser@codeplay.com> |
[VP] Propagate align parameter attr on VP load/store to ISel
This patch fixes a case where the 'align' parameter attribute on the pointer operands to llvm.vp.load and llvm.vp.store was being dropped
[VP] Propagate align parameter attr on VP load/store to ISel
This patch fixes a case where the 'align' parameter attribute on the pointer operands to llvm.vp.load and llvm.vp.store was being dropped during the conversion to the SelectionDAG. The default alignment equal to the ABI type alignment of the vector type was kept. It also updates the documentation to reflect the fact that the parameter attribute is now properly supported.
Reviewed By: simoll
Differential Revision: https://reviews.llvm.org/D114422
show more ...
|
#
a31f4bdf |
| 23-Nov-2021 |
David Sherwood <david.sherwood@arm.com> |
[CodeGen][SVE] Use whilelo instruction when lowering @llvm.get.active.lane.mask
In most common cases the @llvm.get.active.lane.mask intrinsic maps directly to the SVE whilelo instruction, which alre
[CodeGen][SVE] Use whilelo instruction when lowering @llvm.get.active.lane.mask
In most common cases the @llvm.get.active.lane.mask intrinsic maps directly to the SVE whilelo instruction, which already takes overflow into account. However, currently in SelectionDAGBuilder::visitIntrinsicCall we always lower this immediately to a generic sequence of instructions that explicitly take overflow into account. This makes it very difficult to then later transform back into a single whilelo instruction. Therefore, this patch introduces a new TLI function called shouldExpandGetActiveLaneMask that asks if we should lower/expand this to a sequence of generic ISD nodes, or instead just leave it as an intrinsic for the target to lower.
You can see the significant improvement in code quality for some of the tests in this file:
CodeGen/AArch64/active_lane_mask.ll
Differential Revision: https://reviews.llvm.org/D114542
show more ...
|
#
86137fb7 |
| 22-Nov-2021 |
David Sherwood <david.sherwood@arm.com> |
[CodeGen] Add scalable vector support for lowering of llvm.get.active.lane.mask
Currently the generic lowering of llvm.get.active.lane.mask is done in SelectionDAGBuilder::visitIntrinsicCall and cur
[CodeGen] Add scalable vector support for lowering of llvm.get.active.lane.mask
Currently the generic lowering of llvm.get.active.lane.mask is done in SelectionDAGBuilder::visitIntrinsicCall and currently assumes only fixed-width vectors are used. This patch changes the code to be more generic and support scalable vectors too. I have added tests for SVE here:
CodeGen/AArch64/active_lane_mask.ll
although the code quality leaves a lot to be desired. The code will be improved significantly in a later patch that makes use of the SVE whilelo instruction.
Differential Revision: https://reviews.llvm.org/D114541
show more ...
|
#
cf40ca02 |
| 23-Nov-2021 |
David Sherwood <david.sherwood@arm.com> |
[NFC] Tidy up SelectionDAGBuilder::visitIntrinsicCall to use existing sdl debug loc
In quite a few places we were calling getCurSDLoc() to get the debug location, but this is already a local variabl
[NFC] Tidy up SelectionDAGBuilder::visitIntrinsicCall to use existing sdl debug loc
In quite a few places we were calling getCurSDLoc() to get the debug location, but this is already a local variable `sdl`.
Differential Revision: https://reviews.llvm.org/D114447
show more ...
|
#
1e65b93f |
| 23-Nov-2021 |
Simon Moll <simon.moll@emea.nec.com> |
[VP] Canonicalize macros of VPIntrinsics.def
Usage and naming of macros in VPIntrinsics.def has been inconsistent. Rename all property macros to VP_PROPERTY_<name>. Use BEGIN/END scope macros to at
[VP] Canonicalize macros of VPIntrinsics.def
Usage and naming of macros in VPIntrinsics.def has been inconsistent. Rename all property macros to VP_PROPERTY_<name>. Use BEGIN/END scope macros to attach properties to vp intrinsics and SDNodes (instead of specifying either directly with the property macro). A follow-up patch has documentation on how the macros are (intended) to be used.
Reviewed By: frasercrmck
Differential Revision: https://reviews.llvm.org/D114144
show more ...
|
#
32b6c17b |
| 23-Nov-2021 |
David Green <david.green@arm.com> |
[SDAG] Use UnknownSize for masked load/store MMO size
A masked load or store will load a potentially unknown number of bytes from a memory location - that is not generally known at compile time. The
[SDAG] Use UnknownSize for masked load/store MMO size
A masked load or store will load a potentially unknown number of bytes from a memory location - that is not generally known at compile time. They do not necessarily load/store the entire vector width, and treating them as such can lead to incorrect aliasing information (for example, if the underlying object is smaller than the size of the vector).
This makes sure that the MMO is given an unknown size to represent this. which is less accurate that "may load/store from up to 16 bytes", but less incorrect that "will load/store from 16 bytes".
Differential Revision: https://reviews.llvm.org/D113888
show more ...
|
#
b484fa82 |
| 16-Nov-2021 |
Fabian Wolff <fabian.wolff@alumni.ethz.ch> |
[X86] Fix crash with inline asm using wrong register name
Fixes PR#48678. `X86TargetLowering::getRegForInlineAsmConstraint()` can adjust the register class to match the type, e.g. change `VR128X` to
[X86] Fix crash with inline asm using wrong register name
Fixes PR#48678. `X86TargetLowering::getRegForInlineAsmConstraint()` can adjust the register class to match the type, e.g. change `VR128X` to `VR256X` if the type needs 256 bits. However, the function currently returns the unadjusted register and the adjusted register class, e.g. `xmm15` and `VR256X`, which then causes an assertion failure later because the register class does not contain that register. This patch fixes this behavior.
Reviewed By: pengfei
Differential Revision: https://reviews.llvm.org/D113834
show more ...
|
#
81e9c906 |
| 15-Oct-2021 |
Kazu Hirata <kazu@google.com> |
[llvm] Use llvm::is_contained (NFC)
|
#
bd4dad87 |
| 07-Oct-2021 |
Jack Andersen <jackoalan@gmail.com> |
[MachineInstr] Move MIParser's DBG_VALUE RegState::Debug invariant into MachineInstr::addOperand
Based on the reasoning of D53903, register operands of DBG_VALUE are invariably treated as RegState::
[MachineInstr] Move MIParser's DBG_VALUE RegState::Debug invariant into MachineInstr::addOperand
Based on the reasoning of D53903, register operands of DBG_VALUE are invariably treated as RegState::Debug operands. This change enforces this invariant as part of MachineInstr::addOperand so that all passes emit this flag consistently.
RegState::Debug is inconsistently set on DBG_VALUE registers throughout LLVM. This runs the risk of a filtering iterator like MachineRegisterInfo::reg_nodbg_iterator to process these operands erroneously when not parsed from MIR sources.
This issue was observed in the development of the llvm-mos fork which adds a backend that relies on physical register operands much more than existing targets. Physical RegUnit 0 has the same numeric encoding as $noreg (indicating an undef for DBG_VALUE). Allowing debug operands into the machine scheduler correlates $noreg with RegUnit 0 (i.e. a collision of register numbers with different zero semantics). Eventually, this causes an assert where DBG_VALUE instructions are prohibited from participating in live register ranges.
Reviewed By: MatzeB, StephenTozer
Differential Revision: https://reviews.llvm.org/D110105
show more ...
|
#
cfef1803 |
| 26-Sep-2021 |
Amara Emerson <amara@apple.com> |
[GlobalISel] Port over the SelectionDAG stack protector codegen feature.
This is a port of the feature that allows the StackProtector pass to omit checking code for stack canary checks, and rely on
[GlobalISel] Port over the SelectionDAG stack protector codegen feature.
This is a port of the feature that allows the StackProtector pass to omit checking code for stack canary checks, and rely on SelectionDAG to do it at a later stage. The reasoning behind this seems to be to prevent the IR checking instructions from hindering tail-call optimizations during codegen.
Here we allow GlobalISel to also use that scheme. Doing so requires that we do some analysis using some factored-out code to determine where to generate code for the epilogs.
Not every case is handled in this patch since we don't have support for all targets that exercise different stack protector schemes.
Differential Revision: https://reviews.llvm.org/D98200
show more ...
|
#
d34cd75d |
| 03-Oct-2021 |
Kazu Hirata <kazu@google.com> |
[Analysis, CodeGen] Migrate from arg_operands to args (NFC)
Note that arg_operands is considered a legacy name. See llvm/include/llvm/IR/InstrTypes.h for details.
|
#
b62e6f19 |
| 16-Sep-2021 |
Sander de Smalen <sander.desmalen@arm.com> |
[SelectionDAG] Handle promotion + widening in getCopyToPartsVector
Some vectors require both widening and promotion for their legalization. This case is not yet handled in getCopyToPartsVector and f
[SelectionDAG] Handle promotion + widening in getCopyToPartsVector
Some vectors require both widening and promotion for their legalization. This case is not yet handled in getCopyToPartsVector and falls back on scalarizing by default. BBecause scalable vectors can't easily be scalarised, we need to implement this in two separate stages: 1. Widen the vector. 2. Promote the vector.
As part of this patch, PromoteIntRes_CONCAT_VECTORS also needed to be made scalable aware. Instead of falling back on scalarizing the vector (fixed-width only), each sub-part of the CONCAT vector is promoted, and the operation is performed on the type with the widest element type, finally truncating the result to the promoted result type.
Differential Revision: https://reviews.llvm.org/D110646
show more ...
|
#
7255ce30 |
| 27-Sep-2021 |
Itay Bookstein <itay.bookstein@nextsilicon.com> |
[SelectionDAG] Fix incorrect condition for shift amount truncation
Comment says: // If the operand is larger than the shift count type but the shift // count type has enough bits to represent an
[SelectionDAG] Fix incorrect condition for shift amount truncation
Comment says: // If the operand is larger than the shift count type but the shift // count type has enough bits to represent any shift value ...
It clearly talks about the shifted operand, not the shift-amount operand, but the comparison is performed against Log2_32_Ceil(Op2.getValueSizeInBits()) where Op2 is the shift amount operand. This comparison also doesn't make sense in the context of the previous one (ShiftsSize > Op2Size) because Op2Size == Op2.getValueSizeInBits(). Fix to use Op1.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D110509
show more ...
|
#
aa53785f |
| 23-Sep-2021 |
Arthur Eubanks <aeubanks@google.com> |
Reland [clang] Rework dontcall attributes
To avoid using the AST when emitting diagnostics, split the "dontcall" attribute into "dontcall-warn" and "dontcall-error", and also add the frontend attrib
Reland [clang] Rework dontcall attributes
To avoid using the AST when emitting diagnostics, split the "dontcall" attribute into "dontcall-warn" and "dontcall-error", and also add the frontend attribute value as the LLVM attribute value. This gives us all the information to report diagnostics we need from within the IR (aside from access to the original source).
One downside is we directly use LLVM's demangler rather than using the existing Clang diagnostic pretty printing of symbols.
Previous revisions didn't properly declare the new dependencies.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D110364
show more ...
|
#
7833d20f |
| 28-Sep-2021 |
Arthur Eubanks <aeubanks@google.com> |
Revert "[clang] Rework dontcall attributes"
This reverts commit 2943071e2ee0c7f31f34062a44d12aeb0e3a66fd.
Breaks bots
|
#
2943071e |
| 23-Sep-2021 |
Arthur Eubanks <aeubanks@google.com> |
[clang] Rework dontcall attributes
To avoid using the AST when emitting diagnostics, split the "dontcall" attribute into "dontcall-warn" and "dontcall-error", and also add the frontend attribute val
[clang] Rework dontcall attributes
To avoid using the AST when emitting diagnostics, split the "dontcall" attribute into "dontcall-warn" and "dontcall-error", and also add the frontend attribute value as the LLVM attribute value. This gives us all the information to report diagnostics we need from within the IR (aside from access to the original source).
One downside is we directly use LLVM's demangler rather than using the existing Clang diagnostic pretty printing of symbols.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D110364
show more ...
|
#
20b58855 |
| 21-Sep-2021 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
[CodeGen] SelectionDAGBuilder - Use const-ref iterator in for-range loops. NFCI.
Avoid unnecessary copies, reported by MSVC static analyzer.
|
#
0fc624f0 |
| 15-Sep-2021 |
Nikita Popov <nikita.ppv@gmail.com> |
[IR] Return AAMDNodes from Instruction::getMetadata() (NFC)
getMetadata() currently uses a weird API where it populates a structure passed to it, and optionally merges into it. Instead, we can retur
[IR] Return AAMDNodes from Instruction::getMetadata() (NFC)
getMetadata() currently uses a weird API where it populates a structure passed to it, and optionally merges into it. Instead, we can return the AAMDNodes and provide a separate merge() API. This makes usages more compact.
Differential Revision: https://reviews.llvm.org/D109852
show more ...
|
#
e69d4020 |
| 09-Sep-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
[NFC] rename member of BitTestBlock and JumpTableHeader
Follow up to suggestions in D109103 via hans: I think UnreachableDefault (or UnreachableFallthrough) would be a better name now, since it
[NFC] rename member of BitTestBlock and JumpTableHeader
Follow up to suggestions in D109103 via hans: I think UnreachableDefault (or UnreachableFallthrough) would be a better name now, since it doesn't just omit the range check, it also omits the last bit test.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D109455
show more ...
|
#
4331f19d |
| 08-Sep-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
[ISEL][BitTestBlock] omit additional bit test when default destination is unreachable
Otherwise we end up with an extra conditional jump, following by an unconditional jump off the end of a function
[ISEL][BitTestBlock] omit additional bit test when default destination is unreachable
Otherwise we end up with an extra conditional jump, following by an unconditional jump off the end of a function. ie.
bb.0: BT32rr .. JCC_1 %bb.4 ... bb.1: BT32rr .. JCC_1 %bb.2 ... JMP_1 %bb.3 bb.2: ... bb.3.unreachable: bb.4: ...
Should be equivalent to: bb.0: BT32rr .. JCC_1 %bb.4 ... JMP_1 %bb.2 bb.1: bb.2: ... bb.3.unreachable: bb.4: ...
This can occur since at the higher level IR (Instruction) SwitchInsts are required to have BBs for default destinations, even when it can be deduced that such BBs are unreachable.
For most programs, this isn't an issue, just wasted instructions since the unreachable has been statically proven.
The x86_64 Linux kernel when built with CONFIG_LTO_CLANG_THIN=y fails to boot though once D106056 is re-applied. D106056 makes it more likely that correlation-propagation (CVP) can deduce that the default case of SwitchInsts are unreachable. The x86_64 kernel uses a binary post processor called objtool, which emits this warning:
vmlinux.o: warning: objtool: cfg80211_edmg_chandef_valid()+0x169: can't find jump dest instruction at .text.cfg80211_edmg_chandef_valid+0x17b
I haven't debugged precisely why this causes a failure at boot time, but fixing this very obvious jump off the end of the function fixes the warning and boot problem.
Link: https://bugs.llvm.org/show_bug.cgi?id=50080 Fixes: https://github.com/ClangBuiltLinux/linux/issues/679 Fixes: https://github.com/ClangBuiltLinux/linux/issues/1440
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D109103
show more ...
|
#
118997d8 |
| 05-Sep-2021 |
Jonas Paulsson <paulsson@linux.vnet.ibm.com> |
[SelectionDAGBuilder] Bugfix in visitInlineAsm()
In case of a virtual register tied to a phys-def, the register class needs to be computed. Make sure that this works generally also with fast regall
[SelectionDAGBuilder] Bugfix in visitInlineAsm()
In case of a virtual register tied to a phys-def, the register class needs to be computed. Make sure that this works generally also with fast regalloc by using TLI.getRegClassFor() whenever possible, and make only the case of 'Untyped' use getMinimalPhysRegClass().
Fixes https://bugs.llvm.org/show_bug.cgi?id=51699.
Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D109291
show more ...
|
#
3f1f08f0 |
| 02-Sep-2021 |
Roman Lebedev <lebedev.ri@gmail.com> |
Revert @llvm.isnan intrinsic patchset.
Please refer to https://lists.llvm.org/pipermail/llvm-dev/2021-September/152440.html (and that whole thread.)
TLDR: the original patch had no prior RFC, yet i
Revert @llvm.isnan intrinsic patchset.
Please refer to https://lists.llvm.org/pipermail/llvm-dev/2021-September/152440.html (and that whole thread.)
TLDR: the original patch had no prior RFC, yet it had some changes that really need a proper RFC discussion. It won't be productive to discuss such an RFC, once it's actually posted, while said patch is already committed, because that introduces bias towards already-committed stuff, and the tree is potentially in broken state meanwhile.
While the end result of discussion may lead back to the current design, it may also not lead to the current design.
Therefore i take it upon myself to revert the tree back to last known good state.
This reverts commit 4c4093e6e39fe6601f9c95a95a6bc242ef648cd5. This reverts commit 0a2b1ba33ae6dcaedb81417f7c4cc714f72a5968. This reverts commit d9873711cb03ac7aedcaadcba42f82c66e962e6e. This reverts commit 791006fb8c6fff4f33c33cb513a96b1d3f94c767. This reverts commit c22b64ef66f7518abb6f022fcdfd86d16c764caf. This reverts commit 72ebcd3198327da12804305bda13d9b7088772a8. This reverts commit 5fa6039a5fc1b6392a3c9a3326a76604e0cb1001. This reverts commit 9efda541bfbd145de90f7db38d935db6246dc45a. This reverts commit 94d3ff09cfa8d7aecf480e54da9a5334e262e76b.
show more ...
|