is given, override the subtarget settings and enable 64-bit support.
This restores the earlier behavior, and fixes regressions on
Non-64-bit-capable x86-32 hosts.

This isn't necessarily the best approach, but the most obvious
alternative is to require -mcpu=x86-64 or -mattr=+64bit to be used
with -march=x86-64 when the host doesn't have 64-bit support. This
makes things little more consistent, but it's less convenient, and
it has the practical drawback of requiring lots of test changes, so
I opted for the above approach for now.

llvm-svn: 63642

Duncan spotted this. Thanks!

llvm-svn: 63641

accessed at least once as a vector.  This prevents it from
compiling the example in not-a-vector into:

define double @test(double %A, double %B) {
	%tmp4 = insertelement <7 x double> undef, double %A, i32 0
	%tmp = insertelement <7 x double> %tmp4, double %B, i32 4
	%tmp2 = extractelement <7 x double> %tmp, i32 4
	ret double %tmp2
}

instead, producing the integer code.  Producing vectors when they
aren't otherwise in the program is dangerous because a lot of other
code treats them carefully and doesn't want to break them down.
OTOH, many things want to break down tasty i448's.

llvm-svn: 63638

and that sroa doesn't crash.

llvm-svn: 63637

Specify external linkage for such globals so that llvm optimizer do
not assume there values initialized as zero.

llvm-svn: 63636

llvm-svn: 63635

llvm-svn: 63634

in any old order.  Since analyzing a node analyzes its
operands also, this can mean that when we pop a node
off the list of nodes to be analyzed, it may already
have been analyzed.

llvm-svn: 63632

llvm-svn: 63631

are 8-byte aligned.

llvm-svn: 63630

with a specified alignment.

llvm-svn: 63629

ContentCache objects to using a densemap and list, and allocating
the ContentCache objects from a bump pointer.  This does not speed
up or slow down things substantially, but gives us control over 
their alignment.

llvm-svn: 63628

llvm-svn: 63627

llvm-svn: 63626

llvm-svn: 63625

llvm-svn: 63624

llvm-svn: 63623

llvm-svn: 63622

needed to build the LLVM gold plugin.

llvm-svn: 63621

llvm-svn: 63620

(the main point of this restructing).

llvm-svn: 63619

llvm-svn: 63618

acceptable kind with more precise semantics.

llvm-svn: 63617

llvm-svn: 63616

native IRgen type is. This is like Default, but without any extra
semantics (like automatic tweaking of structures or void).

llvm-svn: 63615

llvm-svn: 63614

llvm-svn: 63613

llvm-svn: 63612

 - Still have to convert some consumers over.

llvm-svn: 63610

llvm-svn: 63600

llvm-svn: 63599

initial PHI nodes of the machine function.

llvm-svn: 63598

the index of the value being extracted is always an i32.  This fixes PR3465

llvm-svn: 63597

crazy cases like:

struct f {  int A, B, C, D, E, F; };
short test4() {
  struct f A;
  A.A = 1;
  memset(&A.B, 2, 12);
  return A.C;
}

llvm-svn: 63596

llvm-svn: 63595

llvm-svn: 63594

correct. We need more infrastructure before we can get the DebugLoc info for
these instructions.

llvm-svn: 63593

reliable way to do this with the current dejagnu infrastructure.
If someone can figure out how to fix these tests so that they test
what they are intended to test without spuriously failing on any
popular platforms, they are invited to reinstate them.

llvm-svn: 63592

llvm-svn: 63591

With the new world order, it can handle cases where the first
store into the alloca is an element of the vector, instead of
requiring the first analyzed store to have the vector type 
itself.  This allows us to un-xfail 
test/CodeGen/X86/vec_ins_extract.ll.

llvm-svn: 63590