llvm-svn: 61918

llvm-svn: 61917

loads from allocas that cover the entire aggregate.  This handles
some memcpy/byval cases that are produced by llvm-gcc.  This triggers
a few times in kc++ (with std::pair<std::_Rb_tree_const_iterator
<kc::impl_abstract_phylum*>,bool>) and once in 176.gcc (with %struct..0anon).

llvm-svn: 61915

Again, shamelessly copied from MMI.

llvm-svn: 61912

This is a shameless copy of similar APIs from MachineModuleInfo. The copy from MMI will be deleted in near future.

llvm-svn: 61908

passed in to this function changed to support multiple return values,
leading to some incorrect argument numbers in the failure messages.
With this change, the ArgNo values used for return values and parameters are
disjoint, and the new IntrinsicParam function translates those ArgNo values
to strings that can be used in the messages.  This also fixes a few places
where PerformTypeCheck did not return false following calls to CheckFailed.

llvm-svn: 61903

llvm-svn: 61900

odd bit-width vector elements.  Add a check in the verifier for this also.

llvm-svn: 61899

llvm-svn: 61898

The error was reported by gcc-4.3.0 during compilation.

llvm-svn: 61896

llvm-svn: 61895

llvm-svn: 61893

llvm-svn: 61891

llvm-svn: 61879

was it not very helpful, it was also wrong!  The problem
is shown in the testcase: the alloca might be passed to
a nocapture callee which dereferences it and returns the
original pointer.  But because it was a nocapture call we
think we don't need to track its uses, but we do.

llvm-svn: 61876

llvm-svn: 61873

llvm-svn: 61872

llvm-svn: 61870

integer to a (transitive) bitcast the alloca and if that integer
has the full size of the alloca, then it clobbers the whole thing.
Handle this by extracting pieces out of the stored integer and 
filing them away in the SROA'd elements.

This triggers fairly frequently because the CFE uses integers to
pass small structs by value and the inliner exposes these.  For 
example, in kimwitu++, I see a bunch of these with i64 stores to
"%struct.std::pair<std::_Rb_tree_const_iterator<kc::impl_abstract_phylum*>,bool>"

In 176.gcc I see a few i32 stores to "%struct..0anon".

In the testcase, this is a difference between compiling test1 to:

_test1:
	subl	$12, %esp
	movl	20(%esp), %eax
	movl	%eax, 4(%esp)
	movl	16(%esp), %eax
	movl	%eax, (%esp)
	movl	(%esp), %eax
	addl	4(%esp), %eax
	addl	$12, %esp
	ret

vs:

_test1:
	movl	8(%esp), %eax
	addl	4(%esp), %eax
	ret

The second half of this will be to handle loads of the same form.

llvm-svn: 61853

llvm-svn: 61852

change.

llvm-svn: 61851

requerying it all over the place.

llvm-svn: 61850

code, no functionality change.

llvm-svn: 61849

The coalescer does not coalesce a virtual register to a physical register if any of the physical register's sub-register live intervals overlaps with the virtual register. This is overly conservative. It prevents a extract_subreg from being coalesced away:

v1024 = EDI  // not killed
      =
      = EDI

One possible solution is for the coalescer to examine the sub-register live intervals in the same manner as the physical register. Another possibility is to examine defs and uses (when needed) of sub-registers. Both solutions are too expensive. For now, look for "short virtual intervals" and scan instructions to look for conflict instead.

This is a small win on x86-64. e.g. It shaves 403.gcc by ~80 instructions.

llvm-svn: 61847

into their left operand, rather than their right. Do this
by commuting the operands and inverting the condition.

llvm-svn: 61842

llvm-svn: 61841

llvm-svn: 61836

X86_COND_B and X86_COND_AE, respectively.

llvm-svn: 61835

to handle LLVMMatchType intrinsic parameters, and by adding new subclasses
of LLVMMatchType to match vector types with integral elements that are 
either twice as wide or half as wide as the elements of the matched type.

llvm-svn: 61834

converted to LEA64_32r in x86's convertToThreeAddress. This
replaces code like this:
   movl  %esi, %edi
   inc   %edi
with this:
   lea   1(%rsi), %edi
which appears to be beneficial.

llvm-svn: 61830

- Add preliminary support for v2i32; load/store generates the right code but
  there's a lot work to be done to make this vector type operational.

llvm-svn: 61829

aggregate types. Don't increment the current index after reaching
the end of a struct, as it will already be pointing at
one-past-the end. This fixes PR3288.

llvm-svn: 61828

llvm-svn: 61822

llvm-svn: 61819

two address instructions.  We need to keep track of things we've processed AS USES
independetly of whether we've processed them as defs.

This fixes all known miscompilations when reconstruction is turned on.

llvm-svn: 61802

llvm-svn: 61785

- Fix bugs 3194, 3195: i128 load/stores produce correct code (although, we
  need to ensure that i128 is 16-byte aligned in real life), and 128 zero-
  extends are supported.
- New td file: SPU128InstrInfo.td: this is where all new i128 support should
  be put in the future.
- Continue to hammer on i64 operations and test cases; ensure that the only
  remaining problem will be i64 mul.

llvm-svn: 61784

argument. This doesn't affect current functionality.

llvm-svn: 61779

AddPseudoTwoAddrDeps. This lets the scheduling infrastructure
avoid recalculating node heights. In very large testcases this
was a major bottleneck. Thanks to Roman Levenstein for finding
this!

As a side effect, fold-pcmpeqd-0.ll is now scheduled better
and it no longer requires spilling on x86-32.

llvm-svn: 61778

as template arguments instead of as instance variables, exposing more
optimization opportunities to the compiler earlier.

llvm-svn: 61776