llvm-svn: 141089

llvm-svn: 141088

llvm-svn: 141087

llvm-svn: 141086

llvm-svn: 141085

The set of register classes should be closed under sub-register
operations and intersections. That will allow the register allocator to
model combinations of constraints accurately.

This patch implements the easiest form of register class inference:  For
every register class, and for every sub-register SubIdx, the subset of
registers in RC that have a SubIdx sub-register should also be a register
class.

This does create some new register classes for the targets in the tree:

ARM gets a new QQQQPR_with_ssub_0.  This class was omitted from the .td
file on purpose because it only has two registers.  InstrEmitter and
RegisterCoalescer have safeguards against selecting too small register
classes, so it is harmless.

PowerPC gets a G8RC_with_sub_32 class because LR is not a sub_32
sub-register of LR8.  I think that might be an omission?

X86 puts RIP in the GR64 class, and since that register doesn't have
8-bit sub-registers, we get:

  GR64_with_sub_8bit
  GR64_TC_with_sub_8bit
  GR64_NOREX_with_sub_8bit
  GR64_TC_with_sub_8bit_hi

The various CodeGen classes have already been fixed so adding new
register classes should not affect compile time.

llvm-svn: 141084

This has already been done for most other targets.

llvm-svn: 141083

There is no need to keep the primary order separate.

llvm-svn: 141082

When TableGen starts creating its own register classes, the synthesized
classes won't have a Record reference.  All register classes must have a
name, though.

llvm-svn: 141081

The RecordKeeper could be shared by multiple target instances, causing
duplicate record errors.

llvm-svn: 141080

This patch adds a preprocessor that can expand nested for-loops for
saving some copy-n-paste in *.td files.

The preprocessor is not yet integrated with TGParser, and so it has
no direct effect on *.td inputs.  However, you may preprocess an td
input (and only preprocess it).

To test the proprecessor, type:
  tblgen -E -o $@ $<

llvm-svn: 141079

llvm-svn: 141078

This reverts commit 5383d065241b18e84232bc50d81523f2058ea62b.

llvm-svn: 141077

llvm-svn: 141075

Test: CellSPU/v2i32.ll when running with -promote-elements
llvm-svn: 141074

GCC installation search that requires fewer filesystem operations.
Planning to implement that next as the current approcah while thorough
(and so far looks correct) does a very unfortunate number of filesystem
operations.

I'm motivated to fix this in no small part because I would like to
support a much larger space of triples and GCC versions, which would
explode the current algorithm.

llvm-svn: 141073

find the newest GCC available, among other goodness. It makes the entire
system much less prone to error from prefixes and/or system roots
pruning early the set of triples and GCC versions available.

Also, improve some comments and simplify the forms of some of the loops.

This causes the driver to stat directories more often than is strictly
necessary, but the alternatives which I looked at that still
accomplished this goal needed quite a bit more code and were likely not
much faster.

Test cases for this, now that our behavior here is significantly more
principled and predictable, should come tomorrow as I walk back through
VMs looking for edge cases that are missed after this.

llvm-svn: 141072

significantly cleaner (IMO) and more principled. We now walk down each
layer of the directory hierarchy searching for the GCC install. This
change does in fact introduce a significant behavior change in theory,
although in practice I don't know of any distro that will be impacted by
it negatively, and Debian may (untested) get slightly better through it.

Specifically, the logic now looks exhaustively for patterns such as:

  /usr/lib/<triple>/gcc/<triple>

Previously, this would only be selected if there was *also*
a '/usr/lib/gcc/<triple>' directory, or if '<triple>' were the excat
DefaultHostTriple in the driver.

There is a 4-deep nested loop here, but it doesn't do terribly many
filesystem operations, as we skip at each layer of that layer's
directory doesn't exist.

There remains a significant FIXME in this logic: it would be much better
to first build up a set of candidate components for each of the four
layers with a bottom-up pruning such as this, but then select the final
installation using a top-down algorithm in order to find the newest GCC
installation available, regardless of which particular path leads to it.

llvm-svn: 141071

llvm-svn: 141070

llvm-svn: 141069

llvm-svn: 141068

Otherwise configure fails if gmp is installed in a non default location.

llvm-svn: 141067

llvm-svn: 141066

Add support in the disassembler for ignoring the L-bit on certain VEX instructions. Mark instructions that have this behavior. Fixes PR10676.

llvm-svn: 141065

to id so that we can still optimize them appropriately.

llvm-svn: 141064

This is old leftover cruft from the days when C++ was not yet ready
for prime time.

llvm-svn: 141063

llvm-svn: 141062

-Add the location of the class name to all objc container decls, not just ObjCInterfaceDecl.
-Make objc decls consistent with the rest of the NamedDecls and have getLocation() point to the
 class name, not the location of '@'.

llvm-svn: 141061

llvm-svn: 141060

This handles the case in which LSR rewrites an IV user that is a phi and
splits critical edges originating from a switch.
Fixes <rdar://problem/6453893> LSR is not splitting edges "nicely"

llvm-svn: 141059

llvm-svn: 141058

llvm-svn: 141057

installations. This first selects a set of prefixes and a set of
compatible triples for the current architecture. Once selected, we drive
the search with a single piece of code.

This code isn't particularly efficient as it stands, but its only
executed once. I'm hoping as I clean up the users of this information,
it will also slowly become both cleaner and more efficient.

This also changes the behavior slightly. Previously, we had an ad-hoc
list of prefixes and triples, and we only looked for some triples
beneath specific prefixes and vice versa. This has led to lots of
one-off patches to support triple X, or support lib dir Y. Even without
going to a fully universal driver, we can do better here. This patch
makes us always look first in either 'lib32' or 'lib64' on 32- or 64-bit
hosts (resp.). However, we *always* look in 'lib'.

Currently I have one lingering problem with this strategy. We might find
a newer or better GCC version under a different (but equally compatible)
triple. Fundamentally, this loop needs to be fused with the one below.
That's my next patch.

llvm-svn: 141056

was assembly.  Otherwise, something like -save-temps causes the integrated
assembler to warn.

llvm-svn: 141055

llvm-svn: 141054

using the integrated assembler.
rdar://10216353

llvm-svn: 141053

Unbreaks tools for --enable-shared build.

llvm-svn: 141052

separate thread with the "suitably large" stack, so we don't blow the
stack when building modules recursively.

llvm-svn: 141051

llvm-svn: 141050

llvm-svn: 141049