History log of /llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp (Results 376 – 400 of 2094)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1...<<11121314151617181920>>...84