| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
accumulating estimated cost, and other loop-centric logic from the logic
used to analyze instructions in a particular iteration.
This makes the visitor very narrow in scope -- all it does is visit
instructions, update a map of simplified values, and return whether it
is able to optimize away a particular instruction.
The two cost metrics are now returned as an optional struct. When the
optional is left unengaged, there is no information about the unrolled
cost of the loop, when it is engaged the cost metrics are available to
run against the thresholds.
No functionality changed.
llvm-svn: 238033
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the ISA 2.07 additions involving the
branch history rolling buffer and event-based branching. These will
not be used by typical applications, so built-in support is not
required. They will only be available via inline assembly.
Assembly/disassembly tests are included in the patch.
llvm-svn: 238032
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MachO and COFF quite reasonably only define the size for common symbols.
We used to try to figure out the "size" by computing the gap from one symbol to
the next.
This would not be correct in general, since a part of a section can belong to no
visible symbol (padding, private globals).
It was also really expensive, since we would walk every symbol to find the size
of one.
If a caller really wants this, it can sort all the symbols once and get all the
gaps ("size") in O(n log n) instead of O(n^2).
On MachO this also has the advantage of centralizing all the checks for an
invalid n_sect.
llvm-svn: 238028
|
| |
|
|
| |
llvm-svn: 238027
|
| |
|
|
| |
llvm-svn: 238026
|
| |
|
|
| |
llvm-svn: 238025
|
| |
|
|
|
|
| |
We still detect the same errors, but now we do it earlier.
llvm-svn: 238024
|
| |
|
|
|
|
|
|
|
|
|
| |
The list of subtarget features for the 7em triple contains 't2xtpk',
which actually disables that subtarget feature. Correct that to
'+t2xtpk' and test that the instructions enabled by that feature do
actually work.
Differential Revision: http://reviews.llvm.org/D9936
llvm-svn: 238022
|
| |
|
|
|
|
|
| |
It is explicitly documented to have no effect on object formats where symbols
don't have sizes.
llvm-svn: 238019
|
| |
|
|
| |
llvm-svn: 238018
|
| |
|
|
|
|
| |
DIContext.h, to apease g++-4.7.
llvm-svn: 238012
|
| |
|
|
|
|
|
|
|
|
|
| |
compilers."
Revert "[X86] Refactor the prologue emission to prepare for shrink-wrapping."
This reverts commit 6b3b93fc8b68a2c806aa992ee4bd3d7f61898d4b.
This reverts commit ab0b15dff8539826283a59c2dd700a18a9680e0f.
llvm-svn: 238011
|
| |
|
|
|
|
|
|
|
| |
This change to VirtRegRewriter::addMBBLiveIns adds live-in registers for each
MachineBasicBlock's LiveIns set without isLiveIn checks as they are being added
because doing so is expensive. After all live-in registers are added, the LiveIn
vectors are sorted and uniqued.
llvm-svn: 238008
|
| |
|
|
|
|
|
|
| |
IR using MIR format)."
It brought cyclic dependencies between LLVMCodeGen and LLVMMIR.
llvm-svn: 238007
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Shave a pointer off of `MCSymbolName` by storing `StringMapEntry<bool>*`
instead of `StringRef`. This brings `sizeof(MCSymbol)` down to 64 on
64-bit platforms, a nice round number. My profile showed memory
dropping from 914 MB down to 908 MB, roughly 0.7%. Other than memory
usage, no functionality change here.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
llvm-svn: 238005
|
| |
|
|
|
|
| |
This reverts commit r237975. This seems also to break with gcc 4.7
llvm-svn: 238004
|
| |
|
|
|
|
|
|
|
|
| |
Save a pointer for each `MCSymbol`, bringing `llc` memory usage down
from 920 MB to 914 MB, around ~0.6%.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
llvm-svn: 238003
|
| |
|
|
|
|
|
| |
Lift `MCSymbolData::Index` up a level to `MCSymbol`, as preparation for
packing it into the bitfield in `MCSymbol`.
llvm-svn: 238001
|
| |
|
|
|
|
|
|
|
|
| |
DIContext.h, to appease g++-4.7.
llvm/include/llvm/DebugInfo/DIContext.h:144:11: error: overriding ‘virtual llvm::LoadedObjectInfo::~LoadedObjectInfo() noexcept (true)’
It seems the destructor in the base class may not be "default".
llvm-svn: 238000
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously `SDDbgValue`s used the general allocator that lives for all
of `SelectionDAG`. Instead, give them their own allocator, and reset it
whenever `SDDbgInfo::clear()` is called, plugging a spiritual leak.
This drops `SelectionDAGBuilder::visitIntrinsicCall()` off of my heap
profile (was at around 2% of `llc` for codegen of `-flto -g`). Thanks
to Pete Cooper for spotting the problem and suggesting the fix.
llvm-svn: 237998
|
| |
|
|
|
|
|
|
| |
Cleanup how `SDDbgValue` is initialized, and rearrange the fields to
save two pointers in the struct layout. No real functionality change
though (and I doubt the memory savings would show up in a profile).
llvm-svn: 237997
|
| |
|
|
|
|
| |
This reverts commit r237976, which seems to break existing gcc 4.7 buildbots.
llvm-svn: 237996
|
| |
|
|
|
|
|
|
|
| |
This change does a few things:
- Move some InstCombine transforms to InstSimplify
- Run SimplifyCall from within InstCombine::visitCallInst
- Teach InstSimplify to fold [us]mul_with_overflow(X, undef) to 0.
llvm-svn: 237995
|
| |
|
|
|
|
|
| |
problem instead of suggesting doing something that is trivial to do but
incorrect given the current design of the libraries.
llvm-svn: 237994
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
simplified model for use simulating each iteration into a separate
helper function that just returns the cache.
Building this cache had nothing to do with the rest of the unroll
analysis and so this removes an unnecessary coupling, etc. It should
also make it easier to think about the concept of providing fast cached
access to basic SCEV models as an orthogonal concept to the overall
unroll simulation.
I'd really like to see this kind of caching logic folded into SCEV
itself, it seems weird for us to provide it at this layer rather than
making repeated queries into SCEV fast all on their own.
No functionality changed.
llvm-svn: 237993
|
| |
|
|
|
|
|
|
|
|
|
|
| |
a single location.
This reduces code duplication a bit and will also pave the way for
a better separation between the visitation algorithm and the unroll
analysis.
No functionality changed.
llvm-svn: 237990
|
| |
|
|
|
|
| |
PR23608 pointed out that using the preheader to gain a context instruction isn't always legal because a loop might not have a preheader. When looking into that, I realized that using the preheader to determine legality for sinking is questionable at best. Given no test covers that case and the original commit didn't seem to intend it, I restructured the code to only ask context sensative queries for hoising of loads and stores. This is effectively a partial revert of 237593.
llvm-svn: 237985
|
| |
|
|
|
|
| |
This seems to have caused PR23626: Clang miscompiles webkit's base64 decoder
llvm-svn: 237984
|
| |
|
|
| |
llvm-svn: 237980
|
| |
|
|
|
|
|
|
| |
require it.
(It already was coded assuming it can sometimes be null, so no other changes are necessary)
llvm-svn: 237978
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Add a late pass to expand pseudo instructions (tail call and EH returns).
Instead of doing it in the prologue emission.
- Factor some static methods in X86FrameLowering to ease code sharing.
NFC.
Related to <rdar://problem/20821487>
llvm-svn: 237977
|
| |
|
|
|
|
|
|
| |
As noted in the original review, this is unused in tree & is used by
Julia... that's problematic. This API coudl easily be deleted/modified
by accident without any validation that it remains correct.
llvm-svn: 237976
|
| |
|
|
|
|
|
| |
& remove the duplication by introducing a CRTP base to implement the
clone behavior.
llvm-svn: 237975
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, I can't reduce a small test case for this (although compiling
mpfr-3.1.2 with -O2 -mcpu=a2 would fairly reliably trigger a crash), but the
problem is fairly clear (at least once you know you're looking for one). If the
TLS instruction being replaced was at the end of the block, we'd increment the
iterator past it (so it would then point to MBB.end()), and then we'd increment
it again as part of the for statement, thus overrunning the end of the list.
Don't do that.
llvm-svn: 237974
|
| |
|
|
|
|
|
| |
Caused a miscompile of the Android port of Chromium, details
forthcoming.
llvm-svn: 237972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
x = &a[i];
y = &a[i + j];
=>
y = x + j;
along with some refactoring work such as extracting method
findClosestMatchingDominator.
Depends on D9786 which provides the ScalarEvolution::getGEPExpr interface.
Test Plan: nary-gep.ll
Reviewers: meheff, broune
Reviewed By: broune
Subscribers: jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D9802
llvm-svn: 237971
|
| |
|
|
| |
llvm-svn: 237970
|
| |
|
|
| |
llvm-svn: 237969
|
| |
|
|
|
|
|
|
|
| |
A refactoring made @llvm.ssub.with.overflow.i32(i32 %X, i32 0) transform
into undef instead of %X.
This fixes PR23624.
llvm-svn: 237968
|
| |
|
|
|
|
| |
This is consistent with other uses of the operand list. I'm planning a future commit where this will actually matter.
llvm-svn: 237967
|
| |
|
|
| |
llvm-svn: 237965
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this patch, we could update the operand of another MI in the same
bundle.
Longer version:
Before InlineSpiller rematerializes a vreg, it iterates over operands of each MI
in a bundle, collecting all (MI, OpNo) pairs that reference that vreg.
Then if it does rematerialize, it goes through the pair list and replaces the
operands with the new (rematerialized) vreg. The problem is, it tries to
replace all of these operands in the main MI ! This works fine for single MIs.
However, if we are processing a bundle of MIs and the list contains multiple
pairs - the rematerialization will either crash trying to access a non-existing
operand of the main MI, or silently corrupt one of the existing ones. It will
also ignore other MIs in the bundle.
The obvious fix is to use the MI pointers saved in collected (MI, OpNo) pairs.
This must have been the original intent of the pair list but somehow these
pointers got lost.
Patch by Dmitri Shtilman <dshtilman@icloud.com>!
Differential revision: http://reviews.llvm.org/D9904
<rdar://problem/21002163>
llvm-svn: 237964
|
| |
|
|
|
| |
Phabricator: http://reviews.llvm.org/D9863
llvm-svn: 237963
|
| |
|
|
| |
llvm-svn: 237962
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This supersedes http://reviews.llvm.org/D4010, hopefully properly
dealing with the JIT case and also adds an actual test case.
DwarfContext was basically already usable for the JIT (and back when
we were overwriting ELF files it actually worked out of the box by
accident), but in order to resolve relocations correctly it needs
to know the load address of the section.
Rather than trying to get this out of the ObjectFile or requiring
the user to create a new ObjectFile just to get some debug info,
this adds the capability to pass in that info directly.
As part of this I separated out part of the LoadedObjectInfo struct
from RuntimeDyld, since it is now required at a higher layer.
Reviewers: lhames, echristo
Reviewed By: echristo
Subscribers: vtjnash, friss, rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D6961
llvm-svn: 237961
|
| |
|
|
|
|
| |
Last commit put it in Constants.cpp instead of Operator.cpp
llvm-svn: 237960
|
| |
|
|
|
|
|
|
|
|
|
| |
from the GEP instruction
The raw non-instruction/constant form of this is still relying on being
able to access the pointee type from a pointer type - those will be
cleaned up later. For now, just focus on the cases where the pointee
type is easily accessible.
llvm-svn: 237958
|
| |
|
|
| |
llvm-svn: 237956
|
| |
|
|
| |
llvm-svn: 237955
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is a 2nd attempt at committing the initial MIR serialization patch.
The first commit (r237708) made the incremental buildbots unstable and was
reverted in r237730. The original commit didn't add a terminating null
character to the LLVM IR source which was passed to LLParser, and this
sometimes caused the test 'llvmIR.mir' to fail with a parsing error because
the LLVM IR source didn't have a null character immediately after the end
and thus LLLexer encountered some garbage characters that ultimately caused
the error.
This commit also includes the other test fixes I committed in
r237712 (llc path fix) and r237723 (remove target triple) which
also got reverted in r237730.
--Original Commit Message--
MIR Serialization: print and parse LLVM IR using MIR format.
This commit is the initial commit for the MIR serialization project.
It creates a new library under CodeGen called 'MIR'. This new
library adds a new machine function pass that prints out the LLVM IR
using the MIR format. This pass is then added as a last pass when a
'stop-after' option is used in llc. The new library adds the initial
functionality for parsing of MIR files as well. This commit also
extends the llc tool so that it can recognize and parse MIR input files.
Reviewers: Duncan P. N. Exon Smith, Matthias Braun, Philip Reames
Differential Revision: http://reviews.llvm.org/D9616
llvm-svn: 237954
|