of their elements do not yield the same ParamAttrsList,
though they should. On the other hand, everyone seems
to pass such vectors with elements ordered by increasing
index, so rather than sorting the elements simply assert
that the elements are ordered in this way.
llvm-svn: 41845
Use APFloat in UpgradeParser and AsmParser.
Change all references to ConstantFP to use the
APFloat interface rather than double. Remove
the ConstantFP double interfaces.
Use APFloat functions for constant folding arithmetic
and comparisons.
(There are still way too many places APFloat is
just a wrapper around host float/double, but we're
getting there.)
llvm-svn: 41747
Add APFloat interfaces to ConstantFP, SelectionDAG.
Fix integer bit in double->APFloat conversion.
Convert LegalizeDAG to use APFloat interface in
ConstantFPSDNode uses.
llvm-svn: 41587
use the ValueType name instead of the llvm type name, to match what the
verifier expects. For integers these are the same, but for floating-point
values the intrinsics use f32/f64 instead of float/double.
llvm-svn: 41189
that don't use it don't have to pay the memory cost for the arguments. This
allows us to avoid creating Argument nodes for many prototypes and for clients
who lazily deserialize code from a bytecode file.
llvm-svn: 41166
Into: inttoptr (i64 0 to i8*) -> null
This occurs in the example in PR1602. With this fixed, we now compile
the example in PR1602 into fully "devirtualized" code:
define void @_Z1g1S(%struct.S* noalias %s) {
entry: %tmp131415 = getelementptr %struct.S* %s, i32 0, i32 0 ; <i32 (...)***> [#uses=1] %tmp16 = load i32 (...)*** %tmp131415, align 4 ; <i32 (...)**> [#uses=1]
%tmp26277 = load i32 (...)** %tmp16 ; <i32 (...)*> [#uses=1]
%tmp2829 = bitcast i32 (...)* %tmp26277 to void (%struct.S*)* ; <void (%struct.S*)*> [#uses=1]
tail call void %tmp2829( %struct.S* %s )
ret void
}
This still has the vtable dispatch (as required) but does not have any pointer
to method cruft left.
llvm-svn: 41046
to handle values bigger than double. If we assume host==target and host
long double works correctly, this is not too bad, but we don't want to
have that limitation longterm. I could implement accepting double
constants as long double or something like that, which would lead to
incorrect codegen with no errors; the more I think about that the worse
it seems. Rather than do such a hack that would be backed out later,
I'm settling for giving reasonable error messages, for now.
llvm-svn: 40974
1. domtree is a tree, not a graph. There is no need to avoid revisiting nodes with a set.
2. the worklist can contain the child iterator pointers so we don't get N^2 rescanning of children.
This speeds up updateDFSNumbers significantly, making it basically free. On the testcase in PR1432,
this speeds up loopsimplify by another 3x, dropping it from the 12th most expensive pass to the to
the 30th. :) It used to be #1.
llvm-svn: 40923
natural loop canonicalization (which does many cfg xforms) by 4.3x, for
example. This also fixes a bug in postdom dfnumber computation.
llvm-svn: 40920
2. Make domtree printing print dfin/dfout #'s
3. Fix the Transforms/LoopSimplify/2004-04-13-LoopSimplifyUpdateDomFrontier.ll failure from last night (in DominanceFrontier::splitBlock).
w.r.t. #3, my patches last night happened to expose the bug, but this
has been broken since Owen's r35839 patch to LoopSimplify. The code
was subsequently moved over from LoopSimplify into Dominators, carrying
the latent bug. Fun stuff.
llvm-svn: 40858
DenseMap instead of an std::map. This speeds up postdomtree
by about 25% and domtree by about 23%. It also speeds up clients,
for example, domfrontier by 11%, mem2reg by 4% and ADCE by 6%.
llvm-svn: 40826
This also changes the syntax for llvm.bswap, llvm.part.set, llvm.part.select, and llvm.ct* intrinsics. They are automatically upgraded by both the LLVM ASM reader and the bitcode reader. The test cases have been updated, with special tests added to ensure the automatic upgrading is supported.
llvm-svn: 40807
front end converts regparm attribute on the gcc function into InReg attribute
on the llvm function. This fixes test/CFrontend/2002-07-30-SubrefSetAssertion.c
llvm-svn: 40618
Duncan Sands