| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Add the ability to plug a cache on the LTO API.
I tried to write such that a linker implementation can
control the cache backend. This is intrusive and I'm
not totally happy with it, but I can't figure out a
better design right now.
Differential Revision: https://reviews.llvm.org/D23599
llvm-svn: 279576
|
| |
|
|
|
|
|
| |
There will only be 3 lines of code in foldICmpShrConst() when the cleanup is done,
so it doesn't make much sense to have a separate function for a single fold.
llvm-svn: 279575
|
| |
|
|
|
|
| |
This is a first step towards clarifying the exact MI semantics of stackmap's "live values".
llvm-svn: 279574
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I want to compute the SSA property of .mir files automatically in
upcoming patches. The problem with this is that some inputs will be
reported as static single assignment with some passes claiming not to
support SSA form. In reality though those passes do not support PHI
instructions => Track the presence of PHI instructions separate from the
SSA property.
Differential Revision: https://reviews.llvm.org/D22719
llvm-svn: 279573
|
| |
|
|
| |
llvm-svn: 279569
|
| |
|
|
|
|
|
|
| |
AFAICT, these already worked in all cases for scalar types, and I enhanced
the code to work for vector types in:
https://reviews.llvm.org/rL279543
llvm-svn: 279568
|
| |
|
|
|
|
|
| |
They really should have both types represented, but early variants were created
before MachineInstrs could have multiple types so they're rather ambiguous.
llvm-svn: 279567
|
| |
|
|
|
|
|
| |
Next step is doing both legalizations at the same time! Marvel at GlobalISel's
cunning.
llvm-svn: 279566
|
| |
|
|
| |
llvm-svn: 279565
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-apply this commit with the deletion of a MachineFunction delegated to
a separate pass to avoid use after free when doing this directly in
AsmPrinter.
This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.
This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.
Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.
Differential Revision: http://reviews.llvm.org/D23736
llvm-svn: 279564
|
| |
|
|
|
|
|
| |
No functional change intended, this should just be a code size
improvement.
llvm-svn: 279563
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test case included with r279125 exposed an existing signed integer
overflow. Since getTreeCost can return INT_MAX, we can't sum this cost together
with other costs, such as getReductionCost.
This patch removes the possibility of assigning a cost of INT_MAX. Since we
were previously using INT_MAX as an indicator for "should not vectorize", we
now explicitly check this condition with "isTreeTinyAndNotFullyVectorizable"
before computing a cost.
This patch adds a run-line to the test case used for r279125 that ensures we
don't vectorize. Previously, this line would vectorize the test case by chance
due to undefined behavior in the cost calculation.
Differential Revision: https://reviews.llvm.org/D23723
llvm-svn: 279562
|
| |
|
|
| |
llvm-svn: 279561
|
| |
|
|
|
|
|
| |
Reviewed By: lattner
Differential Revision: https://reviews.llvm.org/D23591
llvm-svn: 279560
|
| |
|
|
|
|
|
| |
The output name changed, but it was passing locally
using the old output still present in the build dir.
llvm-svn: 279556
|
| |
|
|
|
|
|
|
| |
Instructions like G_ICMP have multiple types that may need to be legalized (the
boolean output and nearly arbitrary inputs in this case). So the legalizer must
be capable of deciding what to do for each of them separately.
llvm-svn: 279554
|
| |
|
|
| |
llvm-svn: 279553
|
| |
|
|
|
|
|
|
| |
This adds a test for r279532, thanks David Li for noticing :)
Recommit r279545 after committing first a dependent patch.
llvm-svn: 279551
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LTO object
Summary:
I assume there was a use case, so maybe this strawman patch will help
clarifying if it is legit.
In any case the current situation is not legit: a ThinLTO compilation
should not trigger an unexpected full LTO compilation.
Right now, adding a --save-temps option triggers this and makes the
number of output differs.
Reviewers: tejohnson
Subscribers: pcc, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D23600
llvm-svn: 279550
|
| |
|
|
|
|
|
|
| |
enabled (NFC)"
This reverts commit r279545, test is failing, my Output dir was dirty and making the test pass.
llvm-svn: 279549
|
| |
|
|
|
|
| |
AArch64.
llvm-svn: 279548
|
| |
|
|
|
|
| |
This adds a test for r279532, thanks David Li for noticing :)
llvm-svn: 279545
|
| |
|
|
|
|
| |
Patch by Michael Gorny.
llvm-svn: 279544
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Completes the m_APInt changes for simplifyICmpWithConstant().
Other commits in this series:
https://reviews.llvm.org/rL279492
https://reviews.llvm.org/rL279530
https://reviews.llvm.org/rL279534
https://reviews.llvm.org/rL279538
llvm-svn: 279543
|
| |
|
|
| |
llvm-svn: 279542
|
| |
|
|
| |
llvm-svn: 279538
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This greatly simplifies our handling of SDNode::SubclassData.
NFC, hopefully. :)
See discussion in D23035 for discussion about the design API of these
bitfields.
Reviewers: chandlerc
Subscribers: llvm-commits, rnk
Differential Revision: https://reviews.llvm.org/D23036
llvm-svn: 279537
|
| |
|
|
| |
llvm-svn: 279536
|
| |
|
|
|
|
|
|
| |
other minor fixes.
Differential revision: https://reviews.llvm.org/D23789
llvm-svn: 279535
|
| |
|
|
| |
llvm-svn: 279534
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
appropriate options
An important performance setting on the LLVMContext for LTO is
enableDebugTypeODRUniquing(), this adds an automatic merging of
debug information in the context based on type ids.
Also, the lto::Config includes a diagnostic handler that needs to
be set on the Context, as well as the setDiscardValueNames() setting.
llvm-svn: 279532
|
| |
|
|
|
|
|
|
|
|
|
| |
...because like the corresponding code, this is just too big to keep adding to.
And the next step is to add a vector version of each of these tests to show
missed folds.
Also, auto-generate CHECK lines and add comments for the tests that correspond to
the source code.
llvm-svn: 279530
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That commit added a new version of Intrinsic::getName which should only
be called when the intrinsic has no overloaded types. There are several
debugging paths, such as SDNode::dump which are printing the name of the
intrinsic but don't have the overloaded types. These paths should be ok
to just print the name instead of crashing.
The fix here is ultimately to just add a 'None' second argument as that
calls the overload capable getName, which is less efficient, but this is a
debugging path anyway, and not perf critical.
Thanks to Björn Pettersson for pointing out that there were more crashes.
llvm-svn: 279528
|
| |
|
|
|
|
| |
(v)cvttpd2dq intrinsics implicitly zeroes the upper half of the xmm
llvm-svn: 279527
|
| |
|
|
|
|
| |
Commit r279241 unintentionally reverted that ability.
llvm-svn: 279526
|
| |
|
|
| |
llvm-svn: 279525
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'll rename this to IListTest.cpp after a waiting period (tonight?
tomorrow?), with a full explanation in that commit.
First, I'm moving it aside because Git doesn't play well with case-only
filename changes on case-insensitive file systems (and I suspect the
same is true of SVN). This two-stage change should help to avoid
spurious failures on bots that don't do clean checkouts.
llvm-svn: 279524
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23619
llvm-svn: 279523
|
| |
|
|
|
|
| |
This replaces an =default constructor with an explicit definition.
llvm-svn: 279522
|
| |
|
|
|
|
| |
implicit zero the upper elements
llvm-svn: 279521
|
| |
|
|
| |
llvm-svn: 279520
|
| |
|
|
| |
llvm-svn: 279518
|
| |
|
|
|
|
| |
The windows build bot did not like constexpr.
llvm-svn: 279517
|
| |
|
|
|
|
|
|
|
| |
The change in r279105 causes an infinite loop in some cases, as it sets the upper bits of an AND mask constant, which DAGCombiner::SimplifyDemandedBits then unsets.
This patch reverts that part of the behaviour, instead relying on .td peepholes to perform the transformation to NILL. I reapplied my original fix for the problem addressed by r279105 (unsetting the upper bits, which prevents a compiler abort for a different reason).
Differential Revision: https://reviews.llvm.org/D23781
llvm-svn: 279515
|
| |
|
|
| |
llvm-svn: 279514
|
| |
|
|
|
|
| |
implicitly zeroes the upper half of the xmm
llvm-svn: 279511
|
| |
|
|
| |
llvm-svn: 279510
|
| |
|
|
|
|
| |
"AllTargetsDescs" in llvm-mc/CMakeLists.txt expects not ${target}MCTargetDesc, but ${target}Desc.
llvm-svn: 279509
|
| |
|
|
|
|
| |
zeroes the upper half of the xmm
llvm-svn: 279508
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is not an official documented ABI for frame pointers in Thumb2,
but we should try to emit something which is useful.
We use r7 as the frame pointer for Thumb code, which currently means
that if a function needs to save a high register (r8-r11), it will get
pushed to the stack between the frame pointer (r7) and link register
(r14). This means that while a stack unwinder can follow the chain of
frame pointers up the stack, it cannot know the offset to lr, so does
not know which functions correspond to the stack frames.
To fix this, we need to push the callee-saved registers in two batches,
with the first push saving the low registers, fp and lr, and the second
push saving the high registers. This is already implemented, but
previously only used for iOS. This patch turns it on for all Thumb2
targets when frame pointers are required by the ABI, and the frame
pointer is r7 (Windows uses r11, so this isn't a problem there). If
frame pointer elimination is enabled we still emit a single push/pop
even if we need a frame pointer for other reasons, to avoid increasing
code size.
We must also ensure that lr is pushed to the stack when using a frame
pointer, so that we end up with a complete frame record. Situations that
could cause this were rare, because we already push lr in most
situations so that we can return using the pop instruction.
Differential Revision: https://reviews.llvm.org/D23516
llvm-svn: 279506
|