LLVM now enforces the following prototypes for the write barriers:
<ty>* @llvm.gcread(<ty2>*, <ty>**)
void @llvm.gcwrite(<ty>*, <ty2>*, <ty>**)
And for @llvm.gcroot, the first stack slot is verified to be an alloca or a
bitcast of an alloca.
Fixes test/CodeGen/Generic/GC/lower_gcroot.ll, which violated these.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42051 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new DenseMapInfo::isEqual method to allow clients to redefine
the equality predicate used when probing the hash table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42042 91177308-0d34-0410-b5e6-96231b3b80d8
double from some of the many places in the optimizers
it appears, and do something reasonable with x86
long double.
Make APInt::dump() public, remove newline, use it to
dump ConstantSDNode's.
Allow APFloats in FoldingSet.
Expand X86 backend handling of long doubles (conversions
to/from int, mostly).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41967 91177308-0d34-0410-b5e6-96231b3b80d8
access to bits). Use them in place of float and
double interfaces where appropriate.
First bits of x86 long double constants handling
(untested, probably does not work).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41858 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41845 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41747 91177308-0d34-0410-b5e6-96231b3b80d8
Add APFloat interfaces to ConstantFP, SelectionDAG.
Fix integer bit in double->APFloat conversion.
Convert LegalizeDAG to use APFloat interface in
ConstantFPSDNode uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41587 91177308-0d34-0410-b5e6-96231b3b80d8
This eliminates a conditional on that path, and ensures ICmpInst/FCmpInst
both have an out-of-line virtual method to home the class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41371 91177308-0d34-0410-b5e6-96231b3b80d8
same value which get RAUW'd. This speeds up reading the .bc
file in PR1616 from 852s to 0.19s on my G5 with a debug build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41209 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41189 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41166 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41046 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40974 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40923 91177308-0d34-0410-b5e6-96231b3b80d8
natural loop canonicalization (which does many cfg xforms) by 4.3x, for
example. This also fixes a bug in postdom dfnumber computation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40920 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40858 91177308-0d34-0410-b5e6-96231b3b80d8
speeds up idom by about 45% and postidom by about 33%.
Some extra precautions must be taken not to invalidate densemap iterators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40827 91177308-0d34-0410-b5e6-96231b3b80d8
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%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40826 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40807 91177308-0d34-0410-b5e6-96231b3b80d8
exit edge to preserve LCSSA.
Fix dominance frontier update during loop unswitch. This fixes PR 1589, again
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40737 91177308-0d34-0410-b5e6-96231b3b80d8
