LLVMTargetMachine ctor.  It is currently unused.

llvm-svn: 78711

no longer needs a targetmachine to initialize itself.

llvm-svn: 78710

version.  This allows TAI implementations to specify the directive to use
based on the mode being codegen'd for.

The real fix for this is to remove JumpTableDirective, but I don't feel
like diving into the jumptable snarl just now.

llvm-svn: 78709

the code based on this and make it fall through better.

llvm-svn: 78708

llvm-svn: 78707

something else.

llvm-svn: 78702

llvm-svn: 78701

constant folding eliminated the GEP instruction.
 - clang was hitting this on its test suite (for x86_64, at least).

llvm-svn: 78698

llvm-svn: 78697

llvm-svn: 78696

llvm-svn: 78695

llvm-svn: 78694

FindLineNumber much faster when in sequence.

llvm-svn: 78693

llvm-svn: 78690

llvm-svn: 78689

llvm-svn: 78687

llvm-svn: 78685

llvm-svn: 78683

use them in CreatePtrDiff.

llvm-svn: 78682

llvm-svn: 78680

llvm-svn: 78678

llvm-svn: 78677

other is a subclass of it is effectively handled by the prior tests.

llvm-svn: 78676

llvm-svn: 78671

alignment. Only the minimum alignment guaranteed by the ABI may be assumed.

llvm-svn: 78668

llvm-svn: 78667

llvm-svn: 78666

llvm-svn: 78665

llvm-svn: 78664

llvm-svn: 78663

llvm-svn: 78659

match base only address, i.e. [r] since Thumb2 requires a offset register field.
For those, use [r + imm12] where the immediate is zero.
Note the generated assembly code does not look any different after the patch.
But the bug would have broken the JIT (if there is Thumb2 support) and it can
break later passes which expect the address mode to be well-formed.

llvm-svn: 78658

llvm-svn: 78657

llvm-svn: 78656

llvm-svn: 78655

llvm-svn: 78654

llvm-svn: 78652

llvm-svn: 78651

The register scavenger maintains a DistanceMap that maps MI pointers to their
distance from the top of the current MBB. The DistanceMap is built
incrementally in forward() and in bulk in findFirstUse(). It is used by
scavengeRegister() to determine which candidate register has the longest
unused interval.

Unfortunately the DistanceMap contents can become outdated. The first time
scavengeRegister() is called, the DistanceMap is filled to cover the MBB. If
then instructions are inserted in the MBB (as they always are following
scavengeRegister()), the recorded distances are too short. This causes bad
behaviour in the included test case where a register use /after/ the current
position is ignored because findFirstUse() thinks is is /before/ the current
position. A "using an undefined register" assertion follows promptly.

The fix is to build a fresh DistanceMap at the top of scavengeRegister(), and
discard it after use. This means that DistanceMap is no longer needed as a
RegScavenger member variable, and forward() doesn't need to update it.

The fix then discloses issue number two in the same test case: The candidate
search in scavengeRegister() finds a CSR that has been saved in the prologue,
but is currently unused. It would be both inefficient and wrong to spill such
a register in the emergency spill slot. In the present case, the emergency
slot restore is placed immediately before the normal epilogue restore, leading
to a "Redefining a live register" assertion.

Fix number two: When scavengerRegister() stumbles upon an unused register that
is overwritten later in the MBB, return that register early. It is important
to verify that the register is defined later in the MBB, otherwise it might be
an unspilled CSR.

llvm-svn: 78650

 - Since the function is never called in NDEBUG mode, just dropped the DEBUG()
   uses here.

llvm-svn: 78649