llvm-svn: 78666

llvm-svn: 78665

llvm-svn: 78664

llvm-svn: 78663

llvm-svn: 78662

llvm-svn: 78661

llvm-svn: 78660

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

FriendFunctionDecl, and create instances as appropriate.

The design of FriendFunctionDecl is still somewhat up in the air;  you can
befriend arbitrary types of functions --- methods, constructors, etc. ---
and it's not clear that this representation captures that very well.
We'll have a better picture when we start consuming this data in access
control.

llvm-svn: 78653

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

llvm-svn: 78648

the overloaded vector types allowed floating-point or integer vector elements.
Most of these operations actually depend on the element type, so bitcasting
was not an option.

If you include the vpadd intrinsics that I updated earlier, this gets rid
of 20 intrinsics.

llvm-svn: 78646

generic tree transformation (also used for recanonicalization) and a
small amount of template-instantiation-specific logic.

llvm-svn: 78645

llvm-svn: 78644

llvm-svn: 78643

llvm-svn: 78642

llvm-svn: 78641

llvm-svn: 78640

yet (I'm not even sure what they do).

llvm-svn: 78639

virtual base primaries and improve the layout of classes with virtual
bases.  WIP.

Hey, I've decided I want a change to FileCheck, I need to ensure that
the group is together, nothing in between.  Can we change it to check
the match line is from the line immediately following the last matched
line, if the source for the matched line is immediately after the
source for the previously matched line?

// CHECK: 1
// CHECK: 2
// CHECK: 3

// CHECK: 4
// CHECK: 5
// CHECK: 6

would require 1 2 and 3 to be continuous in the output, and 4 5 and 6
to be continuous.

llvm-svn: 78638

(and outputting a diagnostic pointing at the wrong place), all of which lead to
much confusion.

llvm-svn: 78637

 - This drops us to 123 ambiguous instructions (previously ~500) on X86.

llvm-svn: 78636

Passing of indirect arguments starts after return value on the callee's frame.

llvm-svn: 78635

llvm-svn: 78634

llvm-svn: 78632

arguments that are vectors of any size and element type.

llvm-svn: 78631

INT i8.  These instructions are only for interpretation by disassemblers, not
for emission, so they do not as yet have patterns.

llvm-svn: 78630

llvm-svn: 78629

by defining a LLVM_COMPACT_SENTINELS symbol to 0 or 1 in config.h.

I'm asking for 3 favors:
- may an autofoo expert look at this and suggest improvements?
- may a cmake expert suggest analogous functionality for config.h?
- may somebody with the right autofoo mix regenerate configure? (mine is too new)

Thanks!
--This line, and those below, will be ignored--

M    configure.ac

llvm-svn: 78628

llvm-svn: 78627

and short. Well, it's kinda short. Definitely nasty and brutish.

The front-end generates the register/unregister calls into the SjLj runtime,
call-site indices and landing pad dispatch. The back end fills in the LSDA
with the call-site information provided by the front end. Catch blocks are
not yet implemented.

Built on Darwin and verified no llvm-core "make check" regressions.

llvm-svn: 78625

llvm-svn: 78624