other than PPC64. Instead of fixing it, just remove it and fix all the
places that use it to use TargetData::getPointerSize() instead, as there
aren't very many. Most of the references were in DwarfWriter.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42419 91177308-0d34-0410-b5e6-96231b3b80d8
It includes:
- location and of each safe point in machine code (identified by a
label)
- location of each root within the stack frame (identified by an
offset), including the metadata tag provided to llvm.gcroot in
the user program
- size of the stack frame (for collectors which want to cheat on
stack crawling :)
- and eventually will include liveness
It is to be populated by back-ends during code-generation.
CollectorModuleMetadata aggregates this information across the
entire module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42418 91177308-0d34-0410-b5e6-96231b3b80d8
- Added ability to emit cross class register copies to the BBRU scheduler.
- More aggressive backtracking.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42375 91177308-0d34-0410-b5e6-96231b3b80d8
the check to see if the assembler supports .loc from X86TargetLowering
into the superclass TargetLowering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42297 91177308-0d34-0410-b5e6-96231b3b80d8
bit width instead of number of words allocated, which
makes it actually work for int->APF conversions.
Adjust callers. Add const to one of the APInt constructors
to prevent surprising match when called with const
argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42210 91177308-0d34-0410-b5e6-96231b3b80d8
function. The information isn't used heavily -- it's only used at the end
of exception handling emission -- so there's no need to cache it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42078 91177308-0d34-0410-b5e6-96231b3b80d8
"_-[NSString(local) isNullOrNil]".eh = 0
.no_dead_strip "_-[NSString(local) isNullOrNil]".eh
The ".eh" should be inside the quotes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42074 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
2. Lower calls to fabs and friends to FABS nodes etc unless the function has
internal linkage. Before we wouldn't lower if it had a definition, which
is incorrect. This allows us to compile:
define double @fabs(double %f) {
%tmp2 = tail call double @fabs( double %f )
ret double %tmp2
}
into:
_fabs:
fabs f1, f1
blr
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41805 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
may be the same as the first label for the following
invoke. Remove a micro-optimization which was wrong
in this case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41720 91177308-0d34-0410-b5e6-96231b3b80d8
labels are generated bracketing each call (not just
invokes). This is used to generate entries in
the exception table required by the C++ personality.
However it gets in the way of tail-merging. This
patch solves the problem by no longer placing labels
around ordinary calls. Instead we generate entries
in the exception table that cover every instruction
in the function that wasn't covered by an invoke
range (the range given by the labels around the invoke).
As an optimization, such entries are only generated for
parts of the function that contain a call, since for
the moment those are the only instructions that can
throw an exception [1]. As a happy consequence, we
now get a smaller exception table, since the same
region can cover many calls. While there, I also
implemented folding of invoke ranges - successive
ranges are merged when safe to do so. Finally, if
a selector contains only a cleanup, there's a special
shorthand for it - place a 0 in the call-site entry.
I implemented this while there. As a result, the
exception table output (excluding filters) is now
optimal - it cannot be made smaller [2]. The
problem with throw filters is that folding them
optimally is hard, and the benefit of folding them is
minimal.
[1] I tested that having trapping instructions (eg
divide by zero) in such a region doesn't cause trouble.
[2] It could be made smaller with the help of higher
layers, eg by having branch folding reorder basic blocks
ending in invokes with the same landing pad so they
follow each other. I don't know if this is worth doing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41718 91177308-0d34-0410-b5e6-96231b3b80d8
Implement some constant folding in SelectionDAG and
DAGCombiner using APFloat. Remove double versions
of constructor and getValue from ConstantFPSDNode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41664 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
Changes related modules so VNInfo's are not copied. This decrease
copy coalescing time by 45% and overall compilation time by 10% on siod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41579 91177308-0d34-0410-b5e6-96231b3b80d8
1. Eliminate the costly live interval "swapping".
2. Change ValueNumberInfo container from SmallVector to std::vector. The former
performs slowly when the vector size is very large.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41536 91177308-0d34-0410-b5e6-96231b3b80d8
gcc exception handling: if an exception unwinds through
an invoke, then execution must branch to the invoke's
unwind target. We previously tried to enforce this by
appending a cleanup action to every selector, however
this does not always work correctly due to an optimization
in the C++ unwinding runtime: if only cleanups would be
run while unwinding an exception, then the program just
terminates without actually executing the cleanups, as
invoke semantics would require. I was hoping this
wouldn't be a problem, but in fact it turns out to be the
cause of all the remaining failures in the LLVM testsuite
(these also fail with -enable-correct-eh-support, so turning
on -enable-eh didn't make things worse!). Instead we need
to append a full-blown catch-all to the end of each
selector. The correct way of doing this depends on the
personality function, i.e. it is language dependent, so
can only be done by gcc. Thus this patch which generalizes
the eh.selector intrinsic so that it can handle all possible
kinds of action table entries (before it didn't accomodate
cleanups): now 0 indicates a cleanup, and filters have to be
specified using the number of type infos plus one rather than
the number of type infos. Related gcc patches will cause
Ada to pass a cleanup (0) to force the selector to always
fire, while C++ will use a C++ catch-all (null).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41484 91177308-0d34-0410-b5e6-96231b3b80d8