GlobalISel: allow multiple types on MachineInstrs.

llvm-svn: 276481

GlobalISel: implement low-level type with just size & vector lanes.

This should be all the low-level instruction selection needs to determine how
to implement an operation, with the remaining contex

GlobalISel: implement low-level type with just size & vector lanes.

This should be all the low-level instruction selection needs to determine how
to implement an operation, with the remaining context taken from the opcode
(e.g. G_ADD vs G_FADD) or other flags not based on type (e.g. fast-math).

llvm-svn: 276158

show more ...

[inlineasm] Propagate operand constraints to the backend

When SelectionDAGISel transforms a node representing an inline asm
block, memory constraint information is not preserved. This can cause
cons

[inlineasm] Propagate operand constraints to the backend

When SelectionDAGISel transforms a node representing an inline asm
block, memory constraint information is not preserved. This can cause
constraints to be broken when a memory offset is of the form:

offset + frame index

when the frame is resolved.

By propagating the constraints all the way to the backend, targets can
enforce memory operands of inline assembly to conform to their constraints.

For MIPSR6, some instructions had their offsets reduced to 9 bits from
16 bits such as ll/sc. This becomes problematic when using inline assembly
to perform atomic operations, as an offset can generated that is too big to
encode in the instruction.

Reviewers: dsanders, vkalintris

Differential Review: https://reviews.llvm.org/D21615

llvm-svn: 275786

show more ...

[CodeGen] Refactor MachineMemOperand::Flags's target-specific flags.

Summary:
Make the target-specific flags in MachineMemOperand::Flags real, bona
fide enum values. This simplifies users, prevents

[CodeGen] Refactor MachineMemOperand::Flags's target-specific flags.

Summary:
Make the target-specific flags in MachineMemOperand::Flags real, bona
fide enum values. This simplifies users, prevents various constants
from going out of sync, and avoids the false sense of security provided
by declaring static members in classes and then forgetting to define
them inside of cpp files.

Reviewers: MatzeB

Subscribers: llvm-commits

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

llvm-svn: 275451

show more ...

[CodeGen] Refactor MachineMemOperand's Flags enum.

Summary:
- Give it a shorter name (because we're going to refer to it often from
SelectionDAG and friends).

- Split the flags and alignment into

[CodeGen] Refactor MachineMemOperand's Flags enum.

Summary:
- Give it a shorter name (because we're going to refer to it often from
SelectionDAG and friends).

- Split the flags and alignment into separate variables.

- Specialize FlagsEnumTraits for it, so we can do bitwise ops on it
without losing type information.

- Make some enum values constants in MachineMemOperand instead.
MOMaxBits should not be a valid Flag.

- Simplify some of the bitwise ops for dealing with Flags.

Reviewers: chandlerc

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D22281

llvm-svn: 275438

show more ...

[MI] Clean up some loops over MachineInstr::memoperands(). NFC

Use range-based for loops and llvm::any_of instead of explicit
iterators.

llvm-svn: 275332

[MI] Fix MachineInstr::isInvariantLoad.

Summary:
Previously it would say we had an invariant load if any of the memory
operands were invariant. But the load should be invariant only if *all*
the me

[MI] Fix MachineInstr::isInvariantLoad.

Summary:
Previously it would say we had an invariant load if any of the memory
operands were invariant. But the load should be invariant only if *all*
the memory operands are invariant.

No testcase because this has proven to be very difficult to tickle in
practice. As just one example, ARM's ldrd instruction, which loads 64
bits into two 32-bit regs, is theoretically affected by this. But when
it's produced, it loses its memoperands' invariance bits!

Reviewers: jfb

Subscribers: llvm-commits, aemerson

Differential Revision: http://reviews.llvm.org/D22318

llvm-svn: 275331

show more ...

AMDGPU: Add convergent flag to INLINEASM instruction.

Differential Revision: http://reviews.llvm.org/D21214

llvm-svn: 273455

Pass DebugLoc and SDLoc by const ref.

This used to be free, copying and moving DebugLocs became expensive
after the metadata rewrite. Passing by reference eliminates a ton of
track/untrack operation

Pass DebugLoc and SDLoc by const ref.

This used to be free, copying and moving DebugLocs became expensive
after the metadata rewrite. Passing by reference eliminates a ton of
track/untrack operations. No functionality change intended.

llvm-svn: 272512

show more ...

Fix PR26655: Bail out if all regs of an inst BUNDLE have the correct kill flag

Summary:
While setting kill flags on instructions inside a BUNDLE, we bail out as soon
as we set kill flag on a registe

Fix PR26655: Bail out if all regs of an inst BUNDLE have the correct kill flag

Summary:
While setting kill flags on instructions inside a BUNDLE, we bail out as soon
as we set kill flag on a register. But we are missing a check when all the
registers already have the correct kill flag set. We need to bail out in that
case as well.

This patch refactors the old code and simply makes use of the addRegisterKilled
function in MachineInstr.cpp in order to determine whether to set/remove kill
on an instruction.

Reviewers: apazos, t.p.northover, pete, MatzeB

Subscribers: MatzeB, davide, llvm-commits

Differential Revision: http://reviews.llvm.org/D17356

llvm-svn: 269092

show more ...

AMDGPU/SI: add llvm.amdgcn.ps.live intrinsic

Summary:
This intrinsic returns true if the current thread belongs to a live pixel
and false if it belongs to a pixel that we are executing only for deri

AMDGPU/SI: add llvm.amdgcn.ps.live intrinsic

Summary:
This intrinsic returns true if the current thread belongs to a live pixel
and false if it belongs to a pixel that we are executing only for derivative
computation. It will be used by Mesa to implement gl_HelperInvocation.

Note that for pixels that are killed during the shader, this implementation
also returns true, but it doesn't matter because those pixels are always
disabled in the EXEC mask.

This unearthed a corner case in the instruction verifier, which complained
about a v_cndmask 0, 1, exec, exec<imp-use> instruction. That's stupid but
correct code, so make the verifier accept it as such.

Reviewers: arsenm, tstellarAMD

Subscribers: arsenm, llvm-commits

Differential Revision: http://reviews.llvm.org/D19191

llvm-svn: 267102

show more ...

Sink DI metadata usage out of MachineInstr.h and MachineInstrBuilder.h

MachineInstr.h and MachineInstrBuilder.h are very popular headers,
widely included across all LLVM backends. It turns out that

Sink DI metadata usage out of MachineInstr.h and MachineInstrBuilder.h

MachineInstr.h and MachineInstrBuilder.h are very popular headers,
widely included across all LLVM backends. It turns out that there only a
handful of TUs that actually care about DI operands on MachineInstrs.

After this change, touching DebugInfoMetadata.h and rebuilding llc only
needs 112 actions instead of 542.

llvm-svn: 266351

show more ...

[MachineInstr] Teach the print method about RegisterBank.

Properly print either the register class or the register bank or a
virtual register.
Get rid of a few ifdefs in the process.

llvm-svn: 2657

[MachineInstr] Teach the print method about RegisterBank.

Properly print either the register class or the register bank or a
virtual register.
Get rid of a few ifdefs in the process.

llvm-svn: 265745

show more ...

Revert "NFC: static_assert instead of comment"

This reverts commit fa36fcff16c7d4f78204d6296bf96c3558a4a672.

Causes the following Windows failure:

C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps

Revert "NFC: static_assert instead of comment"

This reverts commit fa36fcff16c7d4f78204d6296bf96c3558a4a672.

Causes the following Windows failure:

C:\Buildbot\Slave\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\lib\CodeGen\MachineInstr.cpp(762):
error C2338: must be trivially copyable to memmove

llvm-svn: 264516

show more ...

NFC: static_assert instead of comment

Summary: isPodLike is as close as we have for is_trivially_copyable.

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D18483

llvm-svn

NFC: static_assert instead of comment

Summary: isPodLike is as close as we have for is_trivially_copyable.

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D18483

llvm-svn: 264515

show more ...

[MachineInstr] Get rid of some GlobalISel ifdefs.

Now the type API is always available, but when global-isel is not
built the implementation does nothing.

Note: The implementation free of ifdefs is

[MachineInstr] Get rid of some GlobalISel ifdefs.

Now the type API is always available, but when global-isel is not
built the implementation does nothing.

Note: The implementation free of ifdefs is WIP and tracked here in PR26576.
llvm-svn: 262873

show more ...

CodeGen: Change MachineInstr to use MachineInstr&, NFC

Change MachineInstr API to prefer MachineInstr& over MachineInstr*
whenever the parameter is expected to be non-null. Slowly inching
toward be

CodeGen: Change MachineInstr to use MachineInstr&, NFC

Change MachineInstr API to prefer MachineInstr& over MachineInstr*
whenever the parameter is expected to be non-null. Slowly inching
toward being able to fix PR26753.

llvm-svn: 262149

show more ...

WIP: CodeGen: Use MachineInstr& in MachineInstrBundle.h, NFC

Update APIs in MachineInstrBundle.h to take and return MachineInstr&
instead of MachineInstr* when the instruction cannot be null. Besid

WIP: CodeGen: Use MachineInstr& in MachineInstrBundle.h, NFC

Update APIs in MachineInstrBundle.h to take and return MachineInstr&
instead of MachineInstr* when the instruction cannot be null. Besides
being a nice cleanup, this is tacking toward a fix for PR26753.

llvm-svn: 262141

show more ...

Minor code cleanups. NFC.

llvm-svn: 261955

MachineInstr: Respect register aliases in clearRegiserKills()

This fixes bugs in copy elimination code in llvm. It slightly changes the
semantics of clearRegisterKills(). This is appropriate because

MachineInstr: Respect register aliases in clearRegiserKills()

This fixes bugs in copy elimination code in llvm. It slightly changes the
semantics of clearRegisterKills(). This is appropriate because:
- Users in lib/CodeGen/MachineCopyPropagation.cpp and
lib/Target/AArch64RedundantCopyElimination.cpp and
lib/Target/SystemZ/SystemZElimCompare.cpp are incorrect without it
(see included testcase).
- All other users in llvm are unaffected (they pass TRI==nullptr)
- (Kill flags are optional anyway so removing too many shouldn't hurt.)

Differential Revision: http://reviews.llvm.org/D17554

llvm-svn: 261763

show more ...

Revert "CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC"

This reverts commit r261504, since it's not obvious the new name is
better:
http://lists.llvm.org/pipermail/llvm-commits/Week

Revert "CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC"

This reverts commit r261504, since it's not obvious the new name is
better:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160222/334298.html

I'll recommit if we get consensus that it's the right direction.

llvm-svn: 261567

show more ...

CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC

Delete MachineInstr::getIterator(), since the term "iterator" is
overloaded when talking about MachineInstr.

- Downcast to ilist_node

CodeGen: MachineInstr::getIterator() => getInstrIterator(), NFC

Delete MachineInstr::getIterator(), since the term "iterator" is
overloaded when talking about MachineInstr.

- Downcast to ilist_node in iplist::getNextNode() and getPrevNode() so
that ilist_node::getIterator() is still available.
- Add it back as MachineInstr::getInstrIterator(). This matches the
naming in MachineBasicBlock.
- Add MachineInstr::getBundleIterator(). This is explicitly called
"bundle" (not matching MachineBasicBlock) to disintinguish it clearly
from ilist_node::getIterator().
- Update all calls. Some of these I switched to `auto` to remove
boiler-plate, since the new name is clear about the type.

There was one call I updated that looked fishy, but it wasn't clear what
the right answer was. This was in X86FrameLowering::inlineStackProbe(),
added in r252578 in lib/Target/X86/X86FrameLowering.cpp. I opted to
leave the behaviour unchanged, but I'll reply to the original commit on
the list in a moment.

llvm-svn: 261504

show more ...

Remove uses of builtin comma operator.

Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.

llvm-svn: 261270

[GlobalISel] Add a type to MachineInstr.
We actually need that information only for generic instructions, therefore it
would be nice not to have to pay the extra memory consumption for all
instructio

[GlobalISel] Add a type to MachineInstr.
We actually need that information only for generic instructions, therefore it
would be nice not to have to pay the extra memory consumption for all
instructions. Especially because a typed non-generic instruction does not make
sense.

The question is then, is it possible to have that information in a union or
something?
My initial thought was that we could have a derived class GenericMachineInstr
with additional information, but in practice it makes little to no sense since
generic MachineInstrs are likely turned into non-generic ones by just switching
the opcode. In other words, we don't want to go through the process of creating
a new, non-generic MachineInstr, object each time we do this switch. The memory
benefit probably is not worth the extra compile time.

Another option would be to keep the type of the MachineInstr in a side table.
This would induce an extra indirection though.

Anyway, I will file a PR to discuss about it and remember we need to come back
to it at some point.

llvm-svn: 260558

show more ...

[GlobalISel][MachineRegisterInfo] Add a method to create generic vregs.
For now, generic virtual registers will not have a register class. We may want
to change that. For instance, if we want to use

[GlobalISel][MachineRegisterInfo] Add a method to create generic vregs.
For now, generic virtual registers will not have a register class. We may want
to change that. For instance, if we want to use all the methods from
TargetRegisterInfo with generic virtual registers, we need to either have some
sort of generic register classes that do what we want, or teach those methods
how to deal with nullptr register class.

Although the latter seems easy enough to do, we may still want to differenciate
generic register classes from nullptr to catch cases where nullptr gets
introduced by a bug of some sort.

Anyway, I will file a PR to keep track of that.

llvm-svn: 260474

show more ...