change is not useful in and of itself, but it lays the groundwork for combining
the dominator and postdominator implementations.
Also, factor a few methods that are common to DominatorTree and PostDominatorTree
into DominatorTreeBase. Again, this will make merging the two calculation methods
simpler in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42248 91177308-0d34-0410-b5e6-96231b3b80d8
fold that were missed in the fix for PR1646. Probably
this null/not-null logic should be factorized somewhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42131 91177308-0d34-0410-b5e6-96231b3b80d8
- The naming prefix is LLVM.
- All types are represented using opaque references.
- Functions are not named LLVM{Type}{Method}; the names became
unreadable goop. Instead, they are named LLVM{ImperativeSentence}.
- Where an attribute only appears once in the class hierarchy (e.g.,
linkage only applies to values; parameter types only apply to
function types), the class is omitted from identifiers for
brevity. Tastes like methods.
- Strings are C strings or string/length tuples on a case-by-case
basis.
- APIs which give the caller ownership of an object are not mapped
(removeFromParent, certain constructor overloads). This keeps
keep memory management as simple as possible.
For each library with bindings:
llvm-c/<LIB>.h - Declares the bindings.
lib/<LIB>/<LIB>.cpp - Implements the bindings.
So just link with the library of your choice and use the C header
instead of the C++ one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42077 91177308-0d34-0410-b5e6-96231b3b80d8
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
