Though I have done extensive testing, it is possible that this will break
things in configs I can't test. Please let me know if this causes a problem
and I'll fix it ASAP.
llvm-svn: 23505
putting it into the constant pool. This allows the isel machinery to
create constants that it will end up deciding are not needed, without them
ending up in the resultant function constant pool.
llvm-svn: 23081
(which died about a week ago) so we're back to load-(2^n-1)-then-AND
sequences. slow, but things should now be Almost Completely Working,
modulo those pesky alignment/ABI issues.
llvm-svn: 22904
be an infinite loop when using g++-4.0.1*, this kills the ia64 nightly
tester. A proper fix shall be forthcoming!!! thanks for not killing me. :)
llvm-svn: 22748
This is the last MVTSDNode.
This allows us to eliminate a bunch of special case code for handling
MVTSDNodes.
Also, remove some uses of dyn_cast that should really be cast (which is
cheaper in a release build).
llvm-svn: 22368
1. Pass Value*'s into lowering methods so that the proper pointers can be
added to load/stores from the valist
2. Intrinsics that return void should only return a token chain, not a token
chain/retval pair.
3. Rename LowerVAArgNext -> LowerVAArg, because VANext is long gone.
4. Now that we have Value*'s available in the lowering methods, pass them
into any load/stores from the valist that are emitted
llvm-svn: 22339
(TRUNK)Stores and (EXT|ZEXT|SEXT)Loads have an extra SDOperand which is a SrcValueSDNode which contains the Value*. Note that if the operation is introduced by the backend, it will still have the operand, but the value* will be null.
llvm-svn: 21599
subtracts. This is a very rough and nasty implementation of Lefevre's
"pattern finding" algorithm. With a few small changes though, it should
end up beating most other methods in common use, regardless of the size
of the constant (currently, it's often one or two shifts worse)
TODO: rewrite it so it's not hideously ugly (this is a translation from
perl, which doesn't help ;)
bypass most of it for multiplies by 2^n+1
(eventually) teach it that some combinations of shift+add are
cheaper than others (e.g. shladd on ia64, scaled adds on alpha)
get it to try multiple booth encodings in search of the cheapest
routine
make it work for negative constants
This is hacked up as a DAG->DAG transform, so once I clean it up I hope
it'll be pulled out of here and put somewhere else. The only thing backends
should really have to worry about for now is where to draw the line
between using this code vs. going ahead and doing an integer multiply
anyway.
llvm-svn: 21560
Chris Lattner