It's just a tPOP instruction with additional code-gen properties, so it
doesn't need encoding information.

llvm-svn: 134172

llvm-svn: 134171

and the RHS of .*.  Noticed by Enea Zaffanella!

llvm-svn: 134170

llvm-svn: 134169

(SourceManager::createFileID cannot return an invalid file ID).
Also update a comment to reflect this.

llvm-svn: 134168

llvm-svn: 134167

This fell out when Chandler landed the patch in r134138.

llvm-svn: 134163

llvm-svn: 134158

llvm-svn: 134156

llvm-svn: 134155

llvm-svn: 134153

In some cases it is necessary to use a version of isl that is more recent than
the one included with CLooG. Point out what is needed to get such a version.

llvm-svn: 134152

llvm-svn: 134148

llvm-svn: 134140

llvm-svn: 134139

a constructor or destructor.

Patch by Hans Wennborg.

llvm-svn: 134138

for a template template parameter.

Uses to follow.

I've also made the uniquing of SubstTemplateTemplateParmPacks
use a ContextualFoldingSet as a minor space efficiency.

llvm-svn: 134137

Patch by Caitlin Sadowski.

Unfortunately, this attribute doesn't seem to have a single test. It is
only mentioned in comments in one test, and as a string literal in
a copy of some Clang code checked in as a test for the Indexer. =[ It
dates from 2009 r74280 as part of OpenCL 1.0.

llvm-svn: 134136

should make it a little easier to use this as an example of
how to fetch all the different bits of information about
threads.

llvm-svn: 134135

llvm-svn: 134134

"struct ", "class ", and "union " from the start of any type names that are
extracted from clang QualType objects. I had to fix test suite cases that
were expecting the struct/union/class prefix to be there.

llvm-svn: 134132

llvm-svn: 134131

tADDrSPi is not predicable, so we can't size-reduce a t2ADDri to it if the
predicate is anything other than "always."

llvm-svn: 134130

llvm-svn: 134129

llvm-svn: 134128

be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.

The fix is to just have the clients explictly pass the CPU name!

llvm-svn: 134127

llvm-svn: 134126

This patch will sometimes choose live range split points next to
interference instead of always splitting next to a register point. That
means spill code can now appear almost anywhere, and it was necessary
to fix code that didn't expect that.

The difficult places were:

- Between a CALL returning a value on the x87 stack and the
  corresponding FpPOP_RETVAL (was FpGET_ST0). Probably also near x87
  inline assembly, but that didn't actually show up in testing.

- Between a CALL popping arguments off the stack and the corresponding
  ADJCALLSTACKUP.

Both are fixed now. The only place spill code can't appear is after
terminators, see SplitAnalysis::getLastSplitPoint.

Original commit message:

Rewrite RAGreedy::splitAroundRegion, now with cool ASCII art.

This function has to deal with a lot of special cases, and the old
version got it wrong sometimes. In particular, it would sometimes leave
multiple uses in the stack interval in a single block. That causes bad
code with multiple reloads in the same basic block.

The new version handles block entry and exit in a single pass. It first
eliminates all the easy cases, and then goes on to create a local
interval for the blocks with difficult interference. Previously, we
would only create the local interval for completely isolated blocks.

It can happen that the stack interval becomes completely empty because
we could allocate a register in all edge bundles, and the new local
intervals deal with the interference. The empty stack interval is
harmless, but we need to remove a SplitKit assertion that checks for
empty intervals.

llvm-svn: 134125

llvm-svn: 134124

Fixes rdar://9643582

llvm-svn: 134123

care about spill values.

llvm-svn: 134122

we didn't have an opcode for 64-bit constant or expressions.

Fixes rdar://9692967

llvm-svn: 134121

TemplateSpecializationType.

llvm-svn: 134120

* Rough in the compact encoding part.

llvm-svn: 134119

the find_global_variables() test method.

Skipping test_find_global_variables_with_dwarf(self) due to segmentation fault.

llvm-svn: 134118

of the encoding.

llvm-svn: 134117

Revert r133953 for now.

llvm-svn: 134116

symbols instead.

llvm-svn: 134115

Unlike Thumb1, Thumb2 does not have dedicated encodings for adjusting the
stack pointer. It can just use the normal add-register-immediate encoding
since it can use all registers as a source, not just R0-R7. The extra
instruction definitions are just duplicates of the normal instructions with
the (not well enforced) constraint that the source register was SP.

llvm-svn: 134114

Some x86-32 calls pop values off the stack, and we need to readjust the
stack pointer after the call. This happens when ADJCALLSTACKUP is
eliminated.

It could happen that spill code was inserted between the CALL and
ADJCALLSTACKUP instructions, and we would compute wrong stack pointer
offsets for those frame index references.

Fix this by inserting the stack pointer adjustment immediately after the
call instead of where the ADJCALLSTACKUP instruction was erased.

I don't have a test case since we don't currently insert code in that
position. We will soon, though. I am testing a regalloc patch that
didn't work on Linux because of this.

llvm-svn: 134113