test/Transforms/SimplifyLibCalls/SPrintF.ll: Suppress this for now. r168677 unveiled another failure.

FYI, this test makes no sense with "not grep"... I saw "assertion failure" in stderr.

llvm-svn: 168679

If the Src and Dst are the same instruction,
no loop-independent dependence is possible,
so we force the PossiblyLoopIndependent flag to false.

The test case results are updated appropriately.

llvm-svn: 168678

This patch migrates the sprintf optimizations from the simplify-libcalls
pass into the instcombine library call simplifier.

llvm-svn: 168677

llvm-svn: 168670

llvm-svn: 168666

llvm-svn: 168665

llvm-svn: 168664

llvm-svn: 168663

llvm-svn: 168661

llvm-svn: 168660

llvm-svn: 168659

llvm-svn: 168658

classes.  The associated test case still doesn't pass, but it does have far
fewer issues.
rdar://12719844

llvm-svn: 168657

Applied the patch, rather than committing it.

llvm-svn: 168656

Revert r168635 "Step towards implementation of pass manager with doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model".
It appears to have broken at least one buildbot.

llvm-svn: 168654

llvm-svn: 168653

llvm-svn: 168652

llvm/test/CodeGen/X86/2012-07-15-broadcastfold.ll: Loosen expression corresponding to r168627. Win32 and *bsd were affected.

llvm-svn: 168651

llvm-svn: 168649

Added in first optimization using fast-math flags to serve as an example for following optimizations. SimplifyInstruction will now try to optimize an fmul observing its FastMathFlags to see if it can fold multiply by zero when 'nnan' and 'nsz' flags are set.

llvm-svn: 168648

llvm-svn: 168647

Added in bitcode enum for the serializing of fast-math flags. Added in the reading/writing of fast-math flags from the OptimizationFlags record for BinaryOps.

llvm-svn: 168646

Added in the ability to read LLVM IR text that contains fast-math flags as a sequence of capital letters separated by spaces in any order. Added in the printing of the fast-math flags in a canonical order, and don't print the other flags when 'fast' is specified, as 'fast' implies all the others.

llvm-svn: 168645

llvm-svn: 168644

add a TODO for starting.

llvm-svn: 168643

Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled.

llvm-svn: 168642

Created FastMathFlags convenience struct for the getting and setting of fast-math flags en masse. Added SubclassOptionalData bitfields and corresponding getters/setters to FPMathOperator for the various fast-math flags.

llvm-svn: 168641

llvm-svn: 168640

llvm-svn: 168638

llvm-svn: 168637

Step towards implementation of pass manager with doInitialization and doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model

Patch by Pedro Artigas, with feedback from by Chandler Carruth.

llvm-svn: 168635

llvm-svn: 168633

It currently assumes register numbering and any harmless change in the X86
register naming makes it fail. It's enough to match the register names.

llvm-svn: 168632

r168627), we no longer need to call the freezeReservedRegs() function a second
time.  Previously, this pass was conservatively adding the FP to the set of
reserved registers, requiring the second update to the reserved registers.
rdar://12719844

llvm-svn: 168631

r168627), we no longer need to call the freezeReservedRegs() function a second
time.  Previously, this pass was conservatively adding the FP to the set of
reserved registers, requiring the second update to the reserved registers.
rdar://12719844

llvm-svn: 168630

InstCombineLoadStoreAlloca.cpp, which had many issues.
(At least two bugs were noted on llvm-commits, and it was overly conservative.)
Instead, use getOrEnforceKnownAlignment.

llvm-svn: 168629

This pass was conservative in that it always reserved the FP to enable dynamic
stack realignment, which allowed the RA to use aligned spills for vector
registers.  This happens even when spills were not necessary.  The RA has 
since been improved to use unaligned spills when necessary.

The new behavior is to realign the stack if the frame pointer was already
reserved for some other reason, but don't reserve the frame pointer just
because a function contains vector virtual registers.

Part of rdar://12719844

llvm-svn: 168627

llvm-svn: 168622

llvm-svn: 168619

llvm-svn: 168617