* Removed trailing whitespace

llvm-svn: 61926

Some generic clean-ups. Also make the StringMapEntryInitializer specialization apply only to the tests that are actually testing it.

llvm-svn: 61923

 StringMapEntryInitializer classes. Leave it for the compiler to figure out what
 the type is and what "0" should be transformed into.

* Un-disable the unit tests which test the StringMapEntryInitializer class.

llvm-svn: 61922

check242, which invalidates this test.  This test is an x86-32 ABI test 
that is trying to be run in a target-independent way, which is not going
to work very well.  Just remove the test.

llvm-svn: 61921

llvm-svn: 61919

llvm-svn: 61918

llvm-svn: 61917

llvm-svn: 61916

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

* Fixed but in StringMap::clear()
* Removed trailing whitespace

Original patch by Talin.

llvm-svn: 61914

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

* Removed trailing whitespace

llvm-svn: 61907

llvm-svn: 61906

whitespace.

llvm-svn: 61905

llvm-svn: 61904

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: 61890

* Fixed {copy,assignment} constructor test names
* s/EXPECT_EQ(true, ...)/ASSERT_TRUE(...)/

Patch by Talin.

llvm-svn: 61883

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

Based on a bug report by Yonggang Luo.

llvm-svn: 61875

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

llvm-svn: 61845

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

llvm-svn: 61842