git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69633 91177308-0d34-0410-b5e6-96231b3b80d8

GEP's don't usually become instructions.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69631 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69630 91177308-0d34-0410-b5e6-96231b3b80d8

  clang: error: unable to make temporary file: /etc/cc: can't make
  unique filename: Permission denied

instead of 

  clang: error: unable to make temporary file: /etc/cc: can't make
  unique filenamePermission denied

for example.

Also, audited the uses of MakeErrMsg to make the prefix strings
consistent (not end with newline/punctuation/space/": ").


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69626 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69624 91177308-0d34-0410-b5e6-96231b3b80d8

in the MachineFunction class, renaming it to addLiveIn for consistency with
the same method in MachineBasicBlock.  Thanks for Anton for suggesting this.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69615 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69613 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69610 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69607 91177308-0d34-0410-b5e6-96231b3b80d8

- Find more reloads from SS.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69606 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69605 91177308-0d34-0410-b5e6-96231b3b80d8

now that errs() is properly non-buffered.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69602 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69599 91177308-0d34-0410-b5e6-96231b3b80d8

which include Functions, where it can be quite useful to use an
AssemblyAnnotationWriter.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69598 91177308-0d34-0410-b5e6-96231b3b80d8

64 bit platforms when building with optimization.
So replace them by a hand-coded implementation.
This fixes PR3822.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69597 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69596 91177308-0d34-0410-b5e6-96231b3b80d8

Added a linearscan register allocation optimization. When the register allocator spill an interval with multiple uses in the same basic block, it creates a different virtual register for each of the reloads. e.g.

	%reg1498<def> = MOV32rm %reg1024, 1, %reg0, 12, %reg0, Mem:LD(4,4) [sunkaddr39 + 0]
        %reg1506<def> = MOV32rm %reg1024, 1, %reg0, 8, %reg0, Mem:LD(4,4) [sunkaddr42 + 0]
        %reg1486<def> = MOV32rr %reg1506
        %reg1486<def> = XOR32rr %reg1486, %reg1498, %EFLAGS<imp-def,dead>
        %reg1510<def> = MOV32rm %reg1024, 1, %reg0, 4, %reg0, Mem:LD(4,4) [sunkaddr45 + 0]

=>

        %reg1498<def> = MOV32rm %reg2036, 1, %reg0, 12, %reg0, Mem:LD(4,4) [sunkaddr39 + 0]
        %reg1506<def> = MOV32rm %reg2037, 1, %reg0, 8, %reg0, Mem:LD(4,4) [sunkaddr42 + 0]
        %reg1486<def> = MOV32rr %reg1506
        %reg1486<def> = XOR32rr %reg1486, %reg1498, %EFLAGS<imp-def,dead>
        %reg1510<def> = MOV32rm %reg2038, 1, %reg0, 4, %reg0, Mem:LD(4,4) [sunkaddr45 + 0]

From linearscan's point of view, each of reg2036, 2037, and 2038 are separate registers, each is "killed" after a single use. The reloaded register is available and it's often clobbered right away. e.g. In thise case reg1498 is allocated EAX while reg2036 is allocated RAX. This means we end up with multiple reloads from the same stack slot in the same basic block.

Now linearscan recognize there are other reloads from same SS in the same BB. So it'll "downgrade" RAX (and its aliases) after reg2036 is allocated until the next reload (reg2037) is done. This greatly increase the likihood reloads from SS are reused.

This speeds up sha1 from OpenSSL by 5.8%. It is also an across the board win for SPEC2000 and 2006.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69585 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69583 91177308-0d34-0410-b5e6-96231b3b80d8

pointer type, make sure that the pointer size is a valid sequential index type.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69574 91177308-0d34-0410-b5e6-96231b3b80d8

freeMachineCodeForFunction was never called.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69531 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69529 91177308-0d34-0410-b5e6-96231b3b80d8

bigger than the vector element type, turn checking
of the operand type back on again, appropriately
adjusted.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69516 91177308-0d34-0410-b5e6-96231b3b80d8

value type union: this field was causing problems for
some compilers on 64 bit systems, presumably because
SimpleTy is 32 bits wide while the other fields are
64 bits wide.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69515 91177308-0d34-0410-b5e6-96231b3b80d8

Fixes segfaults in some corner cases.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69494 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69478 91177308-0d34-0410-b5e6-96231b3b80d8

Turns out that doing this by hand is easier than using autoreconf:-).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69475 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69474 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69473 91177308-0d34-0410-b5e6-96231b3b80d8

patch by Jakob Stoklund Olesen!


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69472 91177308-0d34-0410-b5e6-96231b3b80d8

type as the vector element type: allow them to be of
a wider integer type than the element type all the way
through the system, and not just as far as LegalizeDAG.
This should be safe because it used to be this way
(the old type legalizer would produce such nodes), so
backends should be able to handle it.  In fact only
targets which have legal vector types with an illegal
promoted element type will ever see this (eg: <4 x i16>
on ppc).  This fixes a regression with the new type
legalizer (vec_splat.ll).  Also, treat SCALAR_TO_VECTOR
the same as BUILD_VECTOR.  After all, it is just a
special case of BUILD_VECTOR.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69467 91177308-0d34-0410-b5e6-96231b3b80d8

Configure was not actually regenerated, but the change last time only touched
this one line, so I'm being lazy and cheating by fixing it manually.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69453 91177308-0d34-0410-b5e6-96231b3b80d8

instead of allocating and leaking new SCEVCouldNotCompute objects.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69452 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69451 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69450 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69447 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69446 91177308-0d34-0410-b5e6-96231b3b80d8

building llvm.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69441 91177308-0d34-0410-b5e6-96231b3b80d8

release build of llvm.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69440 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69439 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69438 91177308-0d34-0410-b5e6-96231b3b80d8