llvm-svn: 61990

llvm-svn: 61989

llvm-svn: 61986

I noticed this in the code compiled for a routine using std::map, which produced
this code:
	%25 = tail call i32 @memcmp(i8* %24, i8* %23, i32 6) nounwind readonly
	%.lobit.i = lshr i32 %25, 31		; <i32> [#uses=1]
	%tmp.i = trunc i32 %.lobit.i to i8		; <i8> [#uses=1]
	%toBool = icmp eq i8 %tmp.i, 0		; <i1> [#uses=1]
	br i1 %toBool, label %bb3, label %bb4
which compiled to:

	call	L_memcmp$stub
	shrl	$31, %eax
	testb	%al, %al
	jne	LBB1_11	## 

with this change, we compile it to:

	call	L_memcmp$stub
	testl	%eax, %eax
	js	LBB1_11

This triggers all the time in common code, with patters like this:

	%169 = and i32 %ply, 1		; <i32> [#uses=1]
	%170 = trunc i32 %169 to i8		; <i8> [#uses=1]
	%toBool = icmp ne i8 %170, 0		; <i1> [#uses=1]

 	%7 = lshr i32 %6, 24		; <i32> [#uses=1]
	%9 = trunc i32 %7 to i8		; <i8> [#uses=1]
	%10 = icmp ne i8 %9, 0		; <i1> [#uses=1]

etc

llvm-svn: 61985

llvm-svn: 61984

jump threading can have bugs, who knew? ;-)

llvm-svn: 61983

llvm-svn: 61982

llvm-svn: 61981

llvm-svn: 61980

just llc.

llvm-svn: 61979

llvm-svn: 61978

llvm-svn: 61977

(which is constant time and cheap) before checking hasAllZeroIndices.

llvm-svn: 61976

llvm-svn: 61972

the same formatting as their corresponding SSE2 instructions, for
consistency.

llvm-svn: 61971

llvm-svn: 61969

the comment a little more verbose.

llvm-svn: 61959

Convert DwarfWriter into a pass.
Now Users request DwarfWriter through getAnalysisUsage() instead of creating an instance of DwarfWriter object directly.

llvm-svn: 61955

llvm-svn: 61950

llvm-svn: 61949

llvm-svn: 61948

llvm-svn: 61947

functions that don't already have a (dynamic) alloca.
Dynamic allocas cause inefficient codegen and we shouldn't
propagate this (behavior follows gcc).  Two existing tests
assumed such inlining would be done; they are hacked by
adding an alloca in the caller, preserving the point of
the tests.

llvm-svn: 61946

day when more linkage types will be handled.

llvm-svn: 61944

will get its preferred alignment.  It has to be careful and cautiously assume
it will just get the ABI alignment.  This prevents instcombine from rounding
up the alignment of a load/store without adjusting the alignment of the alloca.

llvm-svn: 61934

llvm-as: t.ll:2:39: function may not return opaque type
  %"bwmoyl" = tail call coldcc opaque @g()
                                      ^
llvm-svn: 61933

llvm-svn: 61932

llvm-svn: 61931

llvm-svn: 61928

* Removed trailing whitespace

llvm-svn: 61927

* 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