[GlobalISel] Handle constant splat in funnel shift combine

This change adds the constant splat versions of m_ICst() (by using
getBuildVectorConstantSplat()) and uses it in
matchOrShiftToFunnelShift(

[GlobalISel] Handle constant splat in funnel shift combine

This change adds the constant splat versions of m_ICst() (by using
getBuildVectorConstantSplat()) and uses it in
matchOrShiftToFunnelShift(). The getBuildVectorConstantSplat() name is
shortened to getIConstantSplatVal() so that the *SExtVal() version would
have a more compact name.

Differential Revision: https://reviews.llvm.org/D125516

show more ...

[GlobalISel] Add matchers for constant splat.

This change exposes isBuildVectorConstantSplat() to the llvm namespace
and uses it to implement the constant splat versions of
m_SpecificICst().

Combin

[GlobalISel] Add matchers for constant splat.

This change exposes isBuildVectorConstantSplat() to the llvm namespace
and uses it to implement the constant splat versions of
m_SpecificICst().

CombinerHelper::matchOrShiftToFunnelShift() can now work with vector
types and CombinerHelper::matchMulOBy2()'s match for a constant splat is
simplified.

Differential Revision: https://reviews.llvm.org/D114625

show more ...

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

Differential Revision: https://reviews.llvm.org/D111454

show more ...

[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 ...

GlobalISel/Utils: Refactor constant splat match functions

Add generic helper function that matches constant splat. It has option to
match constant splat with undef (some elements can be undef but no

GlobalISel/Utils: Refactor constant splat match functions

Add generic helper function that matches constant splat. It has option to
match constant splat with undef (some elements can be undef but not all).
Add util function and matcher for G_FCONSTANT splat.

Differential Revision: https://reviews.llvm.org/D104410

show more ...

GlobalISel/Utils: Refactor integer/float constant match functions

Rework getConstantstVRegValWithLookThrough in order to make it clear if we
are matching integer/float constant only or any constant(

GlobalISel/Utils: Refactor integer/float constant match functions

Rework getConstantstVRegValWithLookThrough in order to make it clear if we
are matching integer/float constant only or any constant(default).
Add helper functions that get DefVReg and APInt/APFloat from constant instr
getIConstantVRegValWithLookThrough: integer constant, only G_CONSTANT
getFConstantVRegValWithLookThrough: float constant, only G_FCONSTANT
getAnyConstantVRegValWithLookThrough: either G_CONSTANT or G_FCONSTANT

Rename getConstantVRegVal and getConstantVRegSExtVal to getIConstantVRegVal
and getIConstantVRegSExtVal. These now only match G_CONSTANT as described
in comment.

Relevant matchers now return both DefVReg and APInt/APFloat.

Replace existing uses of getConstantstVRegValWithLookThrough and
getConstantVRegVal with new helper functions. Any constant match is
only required in:
ConstantFoldBinOp: for constant argument that was bit-cast of float to int
getAArch64VectorSplat: AArch64::G_DUP operands can be any constant
amdgpu select for G_BUILD_VECTOR_TRUNC: operands can be any constant

In other places use integer only constant match.

Differential Revision: https://reviews.llvm.org/D104409

show more ...

[GlobalISel] NFC: Change LLT::vector to take ElementCount.

This also adds new interfaces for the fixed- and scalable case:
* LLT::fixed_vector
* LLT::scalable_vector

The strategy for migrating to t

[GlobalISel] NFC: Change LLT::vector to take ElementCount.

This also adds new interfaces for the fixed- and scalable case:
* LLT::fixed_vector
* LLT::scalable_vector

The strategy for migrating to the new interfaces was as follows:
* If the new LLT is a (modified) clone of another LLT, taking the
same number of elements, then use LLT::vector(OtherTy.getElementCount())
or if the number of elements is halfed/doubled, it uses .divideCoefficientBy(2)
or operator*. That is because there is no reason to specifically restrict
the types to 'fixed_vector'.
* If the algorithm works on the number of elements (as unsigned), then
just use fixed_vector. This will need to be fixed up in the future when
modifying the algorithm to also work for scalable vectors, and will need
then need additional tests to confirm the behaviour works the same for
scalable vectors.
* If the test used the '/*Scalable=*/true` flag of LLT::vector, then
this is replaced by LLT::scalable_vector.

Reviewed By: aemerson

Differential Revision: https://reviews.llvm.org/D104451

show more ...

[MIPatternMatch]: Add matchers for binary instructions

Add matchers that support commutative and non-commutative binary opcodes.

Differential Revision: https://reviews.llvm.org/D99736

[MIPatternMatch]: Add mi_match for MachineInstr

This utility allows more efficient start of pattern match.
Often MachineInstr(MI) is available and instead of using
mi_match(MI.getOperand(0).getReg()

[MIPatternMatch]: Add mi_match for MachineInstr

This utility allows more efficient start of pattern match.
Often MachineInstr(MI) is available and instead of using
mi_match(MI.getOperand(0).getReg(), MRI, ...) followed by
MRI.getVRegDef(Reg) that gives back MI we now use
mi_match(MI, MRI, ...).

Differential Revision: https://reviews.llvm.org/D99735

show more ...

[MIPatternMatch]: Add ICstRegMatch

Matches G_CONSTANT and returns its def register.

Differential Revision: https://reviews.llvm.org/D99734

[GlobalISel] Remove ConstantFoldingMIRBuilder

ConstantFoldingMIRBuilder was an experiment which is not used for
anything. The constant folding functionality is now part of
CSEMIRBuilder.

Differenti

[GlobalISel] Remove ConstantFoldingMIRBuilder

ConstantFoldingMIRBuilder was an experiment which is not used for
anything. The constant folding functionality is now part of
CSEMIRBuilder.

Differential Revision: https://reviews.llvm.org/D101050

show more ...

Revert "[globalisel][unittests] Rename setUp() to avoid potential mix up with SetUp() from gtest"

Forgot to apply commit message changes from phabricator

This reverts commit 3a016e31ecef7eeb876b540

Revert "[globalisel][unittests] Rename setUp() to avoid potential mix up with SetUp() from gtest"

Forgot to apply commit message changes from phabricator

This reverts commit 3a016e31ecef7eeb876b540c928a25a7c5d2e07a.

show more ...

[globalisel][unittests] Rename setUp() to avoid potential mix up with SetUp() from gtest

Also, make it structurally required so it can't be forgotten and re-introduce
the bug that led to the rotten

[globalisel][unittests] Rename setUp() to avoid potential mix up with SetUp() from gtest

Also, make it structurally required so it can't be forgotten and re-introduce
the bug that led to the rotten green tests.

Differential Revision: https://reviews.llvm.org/D99692

show more ...

[MIPatternMatch] Add m_OneNonDBGUse

Add a matcher that checks if the given subpattern has only one non-debug use.

Also improve existing m_OneUse testcase.

Differential Revision: https://reviews.ll

[MIPatternMatch] Add m_OneNonDBGUse

Add a matcher that checks if the given subpattern has only one non-debug use.

Also improve existing m_OneUse testcase.

Differential Revision: https://reviews.llvm.org/D94705

show more ...

[MIPatternMatch] Add matcher for G_PTR_ADD

Add a matcher which recognizes G_PTR_ADD and add a test.

Differential Revision: https://reviews.llvm.org/D94348

[GlobalISel] Add convenience matchers for nots and all-ones constants

Add a convenience matcher which handles

```
G_XOR %not_reg, -1
```

And a convenience matcher which returns true if an integer

[GlobalISel] Add convenience matchers for nots and all-ones constants

Add a convenience matcher which handles

```
G_XOR %not_reg, -1
```

And a convenience matcher which returns true if an integer constant is
all-ones.

Differential Revision: https://reviews.llvm.org/D91459

show more ...

[GlobalISel] Add matchers for specific constants and a matcher for negations

It's fairly common to need matchers for a specific constant value, or for
common idioms like finding a negated register.

[GlobalISel] Add matchers for specific constants and a matcher for negations

It's fairly common to need matchers for a specific constant value, or for
common idioms like finding a negated register.

Add

- `m_SpecificICst`, which returns true when matching a specific value..
- `m_ZeroInt`, which returns true when an integer 0 is matched.
- `m_Neg`, which returns when a register is negated.

Also update a few places which use idioms related to the new matchers.

Differential Revision: https://reviews.llvm.org/D91397

show more ...

GlobalISel: Add matcher for G_SHL

GlobalISel: Prepare to allow other target unit tests

Currently all GlobalISel unittests use a hardcoded AArch64 target
machine. Factor this so I can write some for AMDGPU specific known
bits unittes

GlobalISel: Prepare to allow other target unit tests

Currently all GlobalISel unittests use a hardcoded AArch64 target
machine. Factor this so I can write some for AMDGPU specific known
bits unittests.

show more ...

GlobalISel: Add matcher for G_LSHR

GlobalISel: Add MIPatternMatch for G_ICMP/G_FCMP

[CodeGen] Make use of MachineInstrBuilder::getReg

Reviewers: arsenm

Subscribers: wdng, hiraditya, Petar.Avramovic, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D73262

[GISel] Refactor and split PatternMatchTest. NFC

Split the ConstantFold part into a separate file and
make it use the fixture GISelMITest.

llvm-svn: 374245

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of

[llvm] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

llvm-svn: 369013

show more ...

[globalisel] Add G_SEXT_INREG

Summary:
Targets often have instructions that can sign-extend certain cases faster
than the equivalent shift-left/arithmetic-shift-right. Such cases can be
identified b

[globalisel] Add G_SEXT_INREG

Summary:
Targets often have instructions that can sign-extend certain cases faster
than the equivalent shift-left/arithmetic-shift-right. Such cases can be
identified by matching a shift-left/shift-right pair but there are some
issues with this in the context of combines. For example, suppose you can
sign-extend 8-bit up to 32-bit with a target extend instruction.
%1:_(s32) = G_SHL %0:_(s32), i32 24 # (I've inlined the G_CONSTANT for brevity)
%2:_(s32) = G_ASHR %1:_(s32), i32 24
%3:_(s32) = G_ASHR %2:_(s32), i32 1
would reasonably combine to:
%1:_(s32) = G_SHL %0:_(s32), i32 24
%2:_(s32) = G_ASHR %1:_(s32), i32 25
which no longer matches the special case. If your shifts and extend are
equal cost, this would break even as a pair of shifts but if your shift is
more expensive than the extend then it's cheaper as:
%2:_(s32) = G_SEXT_INREG %0:_(s32), i32 8
%3:_(s32) = G_ASHR %2:_(s32), i32 1
It's possible to match the shift-pair in ISel and emit an extend and ashr.
However, this is far from the only way to break this shift pair and make
it hard to match the extends. Another example is that with the right
known-zeros, this:
%1:_(s32) = G_SHL %0:_(s32), i32 24
%2:_(s32) = G_ASHR %1:_(s32), i32 24
%3:_(s32) = G_MUL %2:_(s32), i32 2
can become:
%1:_(s32) = G_SHL %0:_(s32), i32 24
%2:_(s32) = G_ASHR %1:_(s32), i32 23

All upstream targets have been configured to lower it to the current
G_SHL,G_ASHR pair but will likely want to make it legal in some cases to
handle their faster cases.

To follow-up: Provide a way to legalize based on the constant. At the
moment, I'm thinking that the best way to achieve this is to provide the
MI in LegalityQuery but that opens the door to breaking core principles
of the legalizer (legality is not context sensitive). That said, it's
worth noting that looking at other instructions and acting on that
information doesn't violate this principle in itself. It's only a
violation if, at the end of legalization, a pass that checks legality
without being able to see the context would say an instruction might not be
legal. That's a fairly subtle distinction so to give a concrete example,
saying %2 in:
%1 = G_CONSTANT 16
%2 = G_SEXT_INREG %0, %1
is legal is in violation of that principle if the legality of %2 depends
on %1 being constant and/or being 16. However, legalizing to either:
%2 = G_SEXT_INREG %0, 16
or:
%1 = G_CONSTANT 16
%2:_(s32) = G_SHL %0, %1
%3:_(s32) = G_ASHR %2, %1
depending on whether %1 is constant and 16 does not violate that principle
since both outputs are genuinely legal.

Reviewers: bogner, aditya_nandakumar, volkan, aemerson, paquette, arsenm

Subscribers: sdardis, jvesely, wdng, nhaehnle, rovka, kristof.beyls, javed.absar, hiraditya, jrtc27, atanasyan, Petar.Avramovic, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D61289

llvm-svn: 368487

show more ...