| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
most of the code from here).
Remove the alloc_size.ll test until we settle on a metadata format that makes everyone happy..
llvm-svn: 158920
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- provide more extensive set of functions to detect library allocation functions (e.g., malloc, calloc, strdup, etc)
- provide an API to compute the size and offset of an object pointed by
Move a few clients (GVN, AA, instcombine, ...) to the new API.
This implementation is a lot more aggressive than each of the custom implementations being replaced.
Patch reviewed by Nick Lewycky and Chandler Carruth, thanks.
llvm-svn: 158919
|
| |
|
|
|
|
| |
A patch by Tom Stellard with minor changes.
llvm-svn: 158918
|
| |
|
|
| |
llvm-svn: 158902
|
| |
|
|
|
|
|
|
| |
_umodsi3 libcalls if they have the same arguments. This optimization
was apparently broken if one of the node was replaced in place.
rdar://11714607
llvm-svn: 158900
|
| |
|
|
|
|
| |
Old code would only update physreg live intervals.
llvm-svn: 158881
|
| |
|
|
| |
llvm-svn: 158878
|
| |
|
|
|
|
|
| |
I don't think anyone has been using this functionality for a while, and
it is getting in the way of refactoring now.
llvm-svn: 158876
|
| |
|
|
|
|
| |
Register allocators depend on it being permanently enabled now.
llvm-svn: 158873
|
| |
|
|
|
|
| |
Deterministically enumerate the virtual registers instead.
llvm-svn: 158872
|
| |
|
|
|
|
| |
They are living in LiveRegMatrix now.
llvm-svn: 158868
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop depending on the LiveIntervalUnions in RegAllocBase, they are about
to be removed.
The changes are mostly replacing register alias iterators with regunit
iterators, and querying LiveRegMatrix instrad of RegAllocBase.
InterferenceCache is converted to work with per-regunit
LiveIntervalUnions, and it checks fixed regunit interference separately,
using the fixed live intervals provided by LiveIntervalAnalysis.
The local splitting helper calcGapWeights() is also considering fixed
regunit interference which is kept on the side now.
llvm-svn: 158867
|
| |
|
|
|
|
|
| |
Stop using the LiveIntervalUnions provided by RegAllocBase, they will be
removed soon.
llvm-svn: 158866
|
| |
|
|
|
|
| |
Soon we won't need to compute live intervals for physical registers.
llvm-svn: 158865
|
| |
|
|
|
|
|
| |
Filter out physreg candidates with regunit interferrence.
Also compute regmask interference more efficiently.
llvm-svn: 158864
|
| |
|
|
|
|
|
|
|
|
| |
That is a DenseMap iterator keyed by pointers, so the iteration order is
nondeterministic.
I would like to replace the DenseMap with an IndexedMap which doesn't
allow iteration.
llvm-svn: 158856
|
| |
|
|
| |
llvm-svn: 158855
|
| |
|
|
|
|
|
|
|
|
|
| |
that are generated by TableGen and are already available in
MipsGenRegisterInfo.inc. Suggested by Jakob Stoklund Olesen.
Also, fix bug in function DecodeAFGR64RegisterClass.
Patch by Vladimir Medic.
llvm-svn: 158846
|
| |
|
|
| |
llvm-svn: 158844
|
| |
|
|
| |
llvm-svn: 158841
|
| |
|
|
|
|
| |
node is removed. Sorry, no test case. Foudn it by inspection of the code
llvm-svn: 158839
|
| |
|
|
|
|
|
|
|
|
|
| |
Regunit live ranges are computed on demand, so when mi-sched calls
handleMove, some regunits may not have live ranges yet.
That makes updating them easier: Just skip the non-existing ranges. They
will be computed correctly from the rescheduled machine code when they
are needed.
llvm-svn: 158831
|
| |
|
|
|
|
|
|
|
|
| |
the GEP offset is known to be constant.
With this change, we avoid relying on the IR Builder to constant fold the operations.
No functionality change intended.
llvm-svn: 158829
|
| |
|
|
| |
llvm-svn: 158827
|
| |
|
|
| |
llvm-svn: 158823
|
| |
|
|
|
|
| |
The test case for this will come with the PPC indexed preinc loads commit.
llvm-svn: 158822
|
| |
|
|
| |
llvm-svn: 158820
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a pretty staggering amount of this in LLVM's header files, this
is not all of the instances I'm afraid. These include all of the
functions that (in my build) are used by a non-static inline (or
external) function. Specifically, these issues were caught by the new
'-Winternal-linkage-in-inline' warning.
I'll try to just clean up the remainder of the clearly redundant "static
inline" cases on functions (not methods!) defined within headers if
I can do so in a reliable way.
There were even several cases of a missing 'inline' altogether, or my
personal favorite "static bool inline". Go figure. ;]
llvm-svn: 158800
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'll admit I'm not entirely satisfied with this change, but it seemed
the cleanest option. Other suggestions quite welcome
The issue is that the traits specializations have static methods which
return the typedef'ed PHI_iterator type. In both the IR and MI layers
this is typedef'ed to a custom iterator class defined in an anonymous
namespace giving the types and the functions returning them internal
linkage. However, because the traits specialization is defined in the
'llvm' namespace (where it has to be, specialized template lives there),
and is in turn used in the templated implementation of the SSAUpdater.
This led to the linkage conflict that Clang now warns about.
The simplest solution to me was just to define the PHI_iterator as
a nested class inside the trait specialization. That way it still
doesn't get scoped widely, it can't be accidentally reused somewhere,
etc. This is a little gross just because nested class definitions are
a little gross, but the alternatives seem more ad-hoc.
llvm-svn: 158799
|
| |
|
|
| |
llvm-svn: 158797
|
| |
|
|
| |
llvm-svn: 158795
|
| |
|
|
|
|
| |
vector. Original patch by Elena Demikhovsky. Tweaked by me to allow possibility of covering more cases.
llvm-svn: 158792
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-stable-loops enables a new algorithm for generating the Loop
forest. It differs from the original algorithm in a few respects:
- Not determined by use-list order.
- Initially guarantees RPO order of block and subloops.
- Linear in the number of CFG edges.
- Nonrecursive.
I didn't want to change the LoopInfo API yet, so the block lists are
still inclusive. This seems strange to me, and it means that building
LoopInfo is not strictly linear, but it may not be a problem in
practice. At least the block lists start out in RPO order now. In the
future we may add an attribute or wrapper analysis that allows other
passes to assume RPO order.
The primary motivation of this work was not to optimize LoopInfo, but
to allow reproducing performance issues by decomposing the compilation
stages. I'm often unable to do this with the current LoopInfo, because
the loop tree order determines Loop pass order. Serializing the IR
tends to invert the order, which reverses the optimization order. This
makes it nearly impossible to debug interdependent loop optimizations
such as LSR.
I also believe this will provide more stable performance results across time.
llvm-svn: 158790
|
| |
|
|
| |
llvm-svn: 158788
|
| |
|
|
|
|
|
|
|
| |
The implementation only needs inclusion from LoopInfo.cpp and
MachineLoopInfo.cpp. Clients of the interface should only include the
interface. This makes the interface readable and speeds up rebuilds
after modifying the implementation.
llvm-svn: 158787
|
| |
|
|
|
|
| |
and add unit test. Unix is implemented. Windows side needs to be implemented.
llvm-svn: 158770
|
| |
|
|
|
|
|
|
|
|
| |
llvm::RawMemoryObject handles empty ranges just fine, and the assert can
be triggered in the wild by e.g. invoking clang with a file that
included an empty pre-compiled header file when clang has been built
with assertions enabled. Without assertions enabled, clang will properly
report that the empty file is not a valid PCH.
llvm-svn: 158769
|
| |
|
|
|
|
|
| |
When LiveIntervals is tracking fixed interference in regunits, make sure
to update those intervals as well. Currently guarded by -live-regunits.
llvm-svn: 158766
|
| |
|
|
| |
llvm-svn: 158762
|
| |
|
|
|
|
|
|
|
| |
ensureAlignment() in MachineFunction). Also, drop setMaxAlignment() in
favor of this new function. This creates a main entry point to setting
MaxAlignment, which will be helpful for future work. No functionality
change intended.
llvm-svn: 158758
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds DAG combines to form FMAs from pairs of FADD + FMUL or
FSUB + FMUL. The combines are performed when:
(a) Either
AllowExcessFPPrecision option (-enable-excess-fp-precision for llc)
OR
UnsafeFPMath option (-enable-unsafe-fp-math)
are set, and
(b) TargetLoweringInfo::isFMAFasterThanMulAndAdd(VT) is true for the type of
the FADD/FSUB, and
(c) The FMUL only has one user (the FADD/FSUB).
If your target has fast FMA instructions you can make use of these combines by
overriding TargetLoweringInfo::isFMAFasterThanMulAndAdd(VT) to return true for
types supported by your FMA instruction, and adding patterns to match ISD::FMA
to your FMA instructions.
llvm-svn: 158757
|
| |
|
|
| |
llvm-svn: 158755
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The PPC::EXTSW instruction preserves the low 32 bits of its input, just
like some of the x86 instructions. Use it to reduce register pressure
when the low 32 bits have multiple uses.
This requires a small change to PeepholeOptimizer since EXTSW takes a
64-bit input register.
This is related to PR5997.
llvm-svn: 158743
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 158742
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringMap suffered from the same bug as DenseMap: when you explicitly
construct it with a small number of buckets, you can arrange for the
tombstone-based growth path to be followed when the number of buckets
was less than '8'. In that case, even with a full map, it would compare
'0' as not less than '0', and refuse to grow the table, leading to
inf-loops trying to find an empty bucket on the next insertion. The fix
is very simple: use '<=' as the comparison. The same fix was applied to
DenseMap as well during its recent refactoring.
Thanks to Alex Bolz for the great report and test case. =]
llvm-svn: 158725
|
| |
|
|
|
|
|
|
| |
C89 code.
Should silence warnings when compiling the X86 disassembler.
llvm-svn: 158723
|
| |
|
|
|
|
|
| |
The condition code didn't actually matter for arm "b" instructions,
unlike "bl". It should just use the R_ARM_JUMP24 reloc.
llvm-svn: 158722
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For processors with the G5-like instruction-grouping scheme, this helps avoid
early group termination due to a write-after-write dependency within the group.
It should also help on pipelined embedded cores.
On POWER7, over the test suite, this gives an average 0.5% speedup. The largest
speedups are:
SingleSource/Benchmarks/Stanford/Quicksort - 33%
MultiSource/Applications/d/make_dparser - 21%
MultiSource/Benchmarks/FreeBench/analyzer/analyzer - 12%
MultiSource/Benchmarks/MiBench/telecomm-FFT/telecomm-fft - 12%
Largest slowdowns:
SingleSource/Benchmarks/Stanford/Bubblesort - 23%
MultiSource/Benchmarks/Prolangs-C++/city/city - 21%
MultiSource/Benchmarks/BitBench/uuencode/uuencode - 16%
MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec/mpeg2decode - 13%
llvm-svn: 158719
|
| |
|
|
|
|
| |
empty.
llvm-svn: 158704
|
| |
|
|
| |
llvm-svn: 158702
|