[unwind removal] Remove all of the code for the dead 'unwind' instruction. There
were no 'unwind' instructions being generated before this, so this is in effect
a no-op.

llvm-svn: 149906

SwitchInst refactoring.
The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods t

SwitchInst refactoring.
The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want.

What was done:

1. Changed semantics of index inside the getCaseValue method:
getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous.
2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned.
3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment.
4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst.
4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor.
4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor.

Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang.
llvm-svn: 149481

show more ...

Remove the now-dead llvm.eh.exception and llvm.eh.selector intrinsics.

llvm-svn: 149331

continue making the world safe for ConstantDataVector. At this point,
we should (theoretically optimize and codegen ConstantDataVector as well
as ConstantVector.

llvm-svn: 149116

eliminate the Constant::getVectorElements method. There are better (and
more robust) ways to do what it was doing now. Also, add static methods
for decoding a ShuffleVector mask.

llvm-svn: 149028

Use the right method to get the # elements in a CDS.

llvm-svn: 148897

add more support for ConstantDataSequential

llvm-svn: 148802

More dead code removal (using -Wunreachable-code)

llvm-svn: 148578

Changed flag operand of ISD::FP_ROUND to TargetConstant as it should not get checked for legalisation

llvm-svn: 148275

Changed intrinsic ID operand to a target constant as its not used in any arithmetic so should not be checked in legalisation

llvm-svn: 148228

Allow vector shuffle normalizing to use concat vector even if the sources are commuted in the shuffle mask.

llvm-svn: 147527

Turn a few more inline asm errors into "emitErrors" instead of fatal errors.

Before we'd get:

$ clang t.c
fatal error: error in backend: Invalid operand for inline asm constraint 'i'!

Now we get:

Turn a few more inline asm errors into "emitErrors" instead of fatal errors.

Before we'd get:

$ clang t.c
fatal error: error in backend: Invalid operand for inline asm constraint 'i'!

Now we get:

$ clang t.c
t.c:16:5: error: invalid operand for inline asm constraint 'i'!
"movq (%4), %%mm0\n"
^

Which at least gets us the inline asm that is the problem.

llvm-svn: 147502

show more ...

Remove the restriction that target intrinsics can only involve legal types. Targets can perfects well support intrinsics on illegal types, as long as they are prepared to perform custom expansion du

Remove the restriction that target intrinsics can only involve legal types. Targets can perfects well support intrinsics on illegal types, as long as they are prepared to perform custom expansion during type legalization. For example, a target where i64 is illegal might still support the i64 intrinsic operation using pairs of i32's. ARM already does some expansions like this for non-intrinsic operations.

llvm-svn: 147472

show more ...

Add some constantness to BranchProbabilityInfo and BlockFrequnencyInfo.

llvm-svn: 146986

Enable synthesis of FLOG2 and FEXP2 SelectionDAG nodes from libm calls. These are already marked as illegal by default.

llvm-svn: 146623

Initial CodeGen support for CTTZ/CTLZ where a zero input produces an
undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef b

Initial CodeGen support for CTTZ/CTLZ where a zero input produces an
undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.

Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.

Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.

llvm-svn: 146466

show more ...

Enhance both TargetLibraryInfo and SelectionDAGBuilder so that the latter can use the former to prevent the formation of libm SDNode's when -fno-builtin is passed.

llvm-svn: 146193

Teach SelectionDAG to match more calls to libm functions onto existing SDNodes. Mark these nodes as illegal by default, unless the target declares otherwise.

llvm-svn: 146171

Add support for vectors of pointers.

llvm-svn: 145801

Move global variables in TargetMachine into new TargetOptions class. As an API
change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.

One small functionality c

Move global variables in TargetMachine into new TargetOptions class. As an API
change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.

One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.

llvm-svn: 145714

show more ...

Remove dead llvm.eh.sjlj.dispatchsetup intrinsic.

llvm-svn: 145263

Fix an obvious omission in the SelectionDAGBuilder where we were
dropping weights on the floor for invokes. This was impeding my writing
further test cases for invoke when interacting with probabilit

Fix an obvious omission in the SelectionDAGBuilder where we were
dropping weights on the floor for invokes. This was impeding my writing
further test cases for invoke when interacting with probabilities and
block placement.

No test case as there doesn't appear to be a way to test this stuff. =/
Suggestions for a test case of course welcome. I hope to be able to add
test cases that indirectly cover this eventually by adding probabilities
to the exceptional edge and reordering blocks as a result.

llvm-svn: 145060

show more ...

Remove some unnecessary includes of PseudoSourceValue.h.

llvm-svn: 144634

Added invariant field to the DAG.getLoad method and changed all calls.

When this field is true it means that the load is from constant (runt-time or compile-time) and so can be hoisted from loops or

Added invariant field to the DAG.getLoad method and changed all calls.

When this field is true it means that the load is from constant (runt-time or compile-time) and so can be hoisted from loops or moved around other memory accesses

llvm-svn: 144100

show more ...

Don't use floating point to do an integer's job.

This code makes different decisions when compiled into x87 instructions
because of different rounding behavior. That caused phase 2/3
miscompares on

Don't use floating point to do an integer's job.

This code makes different decisions when compiled into x87 instructions
because of different rounding behavior. That caused phase 2/3
miscompares on 32-bit Linux when the phase 1 compiler was built with gcc
(using x87), and the phase 2 compiler was built with clang (using SSE).

This fixes PR11200.

llvm-svn: 143006

show more ...