llvm-svn: 65962

llvm-svn: 65961

llvm-svn: 65960

llvm-svn: 65945

llvm-svn: 65942

llvm-svn: 65936

llvm-svn: 65934

and put @file directives on their own comment line.

llvm-svn: 65920

(lest they affect codegen).

llvm-svn: 65915

info with it.
Don't count debug info insns against the scan maximum
in FindAvailableLoadedValue (lest they affect codegen).

llvm-svn: 65910

llvm-svn: 65908

If branch conditions' one successor is dominating another non-latch successor then this loop's iteration space can not be restricted. In this example block bb5 is always executed.

llvm-svn: 65902

arbitrary vector sizes.  Add an optional MinSplatBits parameter to specify
a minimum for the splat element size.  Update the PPC target to use the
revised interface.

llvm-svn: 65899

llvm-svn: 65895

This is ugly, but I can't figure out a quick way out of this.

llvm-svn: 65889

Ed Schouten!

llvm-svn: 65882

clean up when using variable length arrays in llvm-gcc.

llvm-svn: 65832

Move the code from 'llvmc/driver' into a new CompilerDriver library, and change
the build system accordingly. Makes it easier for projects using LLVM to build
their own llvmc-based drivers.

Tested with objdir != srcdir.

llvm-svn: 65821

extracts + build_vector into a shuffle would fail, because the
type of the new build_vector would not be legal.  Try harder to
create a legal build_vector type.  Note: this will be totally 
irrelevant once vector_shuffle no longer takes a build_vector for
shuffle mask.

New:
_foo:
	xorps	%xmm0, %xmm0
	xorps	%xmm1, %xmm1
	subps	%xmm1, %xmm1
	mulps	%xmm0, %xmm1
	addps	%xmm0, %xmm1
	movaps	%xmm1, 0

Old:
_foo:
	xorps	%xmm0, %xmm0
	movss	%xmm0, %xmm1
	xorps	%xmm2, %xmm2
	unpcklps	%xmm1, %xmm2
	pshufd	$80, %xmm1, %xmm1
	unpcklps	%xmm1, %xmm2
	pslldq	$16, %xmm2
	pshufd	$57, %xmm2, %xmm1
	subps	%xmm0, %xmm1
	mulps	%xmm0, %xmm1
	addps	%xmm0, %xmm1
	movaps	%xmm1, 0

llvm-svn: 65791

be a win, since almost every interesting function has at least one Argument.

llvm-svn: 65778

its sentinel. This is quite a win when a function really has a basic block.                  
When the function is just a declaration (and stays so) the old way did not
allocate a sentinel. So this change is most beneficial when the ratio of
function definition to declaration is high. I.e. linkers etc. Incidentally  
these are the most resource demanding applications, so I expect that the
reduced malloc traffic, locality and space savings outweigh the cost of
addition of two pointers to Function.

llvm-svn: 65776

testsuite:

Running /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/dg.exp ...
FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/nancvt.ll
Failed with exit(1) at line 2
while running: grep 2147027116 nancvt.ll.tmp | count 3
count: expected 3 lines and got        0.
child process exited abnormally
FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/vec_ins_extract.ll
Failed with exit(1) at line 1
while running:  llvm-as < /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/CodeGen/X86/vec_ins_extract.ll |  opt -scalarrepl -instcombine |   llc -march=x86 -mcpu=yonah | not /usr/bin/grep sub.*esp
      subl      $28, %esp
      subl      $28, %esp
child process exited abnormally

And more.

llvm-svn: 65758

as well as isSafeAllocaToScalarRepl.

llvm-svn: 65755

Look for situations like this:                                                                                                                                                              
%reg1024<def> = MOV r1                                                                                                                                                                      
%reg1025<def> = MOV r0                                                                                                                                                                      
%reg1026<def> = ADD %reg1024, %reg1025                                                                                                                                                      
r0            = MOV %reg1026                                                                                                                                                                
Commute the ADD to hopefully eliminate an otherwise unavoidable copy.

llvm-svn: 65752

stuff like %A = type { %A*} instead of an upref.

llvm-svn: 65748

method in a BuildVectorSDNode "pseudo-class".

llvm-svn: 65747

types.  This was reading the uint for the keyword after the token was advanced.

llvm-svn: 65743

	type opaque		; type %0
	%C = type { %0, %0 }

instead of:

	%C = type { opaque, opaque }

when appropriate.

llvm-svn: 65742

stripped .bc file, it didn't make any attempt to try to reuse anonymous types.
This causes an amazing type explosion due to types getting duplicated everywhere
they are referenced and other problems.

This also caused correctness issues, because opaque types are unique for each time
they are uttered in the file.  This means that stripping a .bc file could produce
a .ll file that could not be assembled (e.g. 2009-02-28-StripOpaqueName.ll).

This patch fixes both of these issues.

llvm-svn: 65738

AsmWriter.cpp method.

llvm-svn: 65736

llvm-svn: 65735

stuff in AsmWriter.cpp for Type::getDescription().

llvm-svn: 65734

llvm-svn: 65733

llvm-svn: 65729

llvm-svn: 65724

llvm-svn: 65723

llvm-svn: 65722

llvm-svn: 65721

the old std::ostream version.

llvm-svn: 65720

eliminate redundant opaque handling code.

llvm-svn: 65716