| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 283689
|
| |
|
|
| |
llvm-svn: 283687
|
| |
|
|
| |
llvm-svn: 283686
|
| |
|
|
|
|
| |
created by the current process
llvm-svn: 283682
|
| |
|
|
| |
llvm-svn: 283676
|
| |
|
|
| |
llvm-svn: 283675
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template
The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when calling:
va_start(ValueArgs, Desc);
with Desc being a StringRef.
Differential Revision: https://reviews.llvm.org/D25342
llvm-svn: 283671
|
| |
|
|
|
|
|
|
| |
VR128X/VR256X even when VLX isn't supported.
This seems to have been responsible for the XMM16-31 spills observed in PR29112. With this fixed the test case has been modified to no longer have a spill of XMM16.
llvm-svn: 283668
|
| |
|
|
|
|
| |
restriction rather than implying it from TypeJR.
llvm-svn: 283665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When there is a call to an alias in the same module, we were not
adding a call edge. So we could incorrectly think that the alias
was dead if it was inlined in that function, despite having a
reference imported elsewhere. This resulted in unsats at link time.
Add a call edge when the call is to an alias.
Reviewers: davide, mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25384
llvm-svn: 283664
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid generating indexed vector instructions for Exynos. This is needed for
fmla/fmls/fmul/fmulx. For example, the instruction
fmla v0.4s, v1.4s, v2.s[1]
is less efficient than the instructions
dup v2.4s, v2.s[1]
fmla v0.4s, v1.4s, v2.4s
Patch written by Abderrazek Zaafrani.
Differential Revision: https://reviews.llvm.org/D21571
llvm-svn: 283663
|
| |
|
|
|
|
|
|
|
|
|
| |
Value names may be prefixed with a binary '1' to indicate that the
backend should not modify the symbols due to any platform naming
convention.
This should not show up in the YAML opt record file because it breaks
the YAML parser.
llvm-svn: 283656
|
| |
|
|
|
|
|
|
|
| |
Clang always emit a hash for ThinLTO, but as other frontend are
starting to use ThinLTO, this could be a serious bug.
Differential Revision: https://reviews.llvm.org/D25379
llvm-svn: 283655
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We need to add an entry in the combined-index for modules that have
a hash but otherwise empty summary, this is needed so that we can
get the hash for the module.
Also, if no entry is present in the combined index for a module, we
need to skip it when trying to compute a cache entry.
Differential Revision: https://reviews.llvm.org/D25300
llvm-svn: 283654
|
| |
|
|
|
|
| |
This reverts commit 71c312652c10f1855b28d06697c08d47e7a243e4.
llvm-svn: 283647
|
| |
|
|
| |
llvm-svn: 283642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first step towards round-tripping symbol information,
and thusly being able to write symbol information to a PDB.
This patch writes the symbol information for each compiland to
the Yaml when running in pdb2yaml mode. There's still some loose
ends, such as what to do about relocations (necessary in order to
print linkage names), how to print enums with friendly names, and
how to give the dumper access to the StringTable, but this is a
good first start.
llvm-svn: 283641
|
| |
|
|
|
|
| |
This wasn't looking at the right instruction, and would always fail.
llvm-svn: 283640
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We previously only used the frame pointer if the frame pointer was too
big. This was to work around a bug (described in this old commit)
https://sourceforge.net/p/avr-llvm/code/204/tree//llvm/trunk/AVR/AVRFrameLowering.cpp?diff=50d64d912718465cb887d17a:203
I mistakenly invered the condition assuming it was a typo. I am now
removing it because it doesn't seem to be a problem anymore (plus it's a
dirty hack).
llvm-svn: 283639
|
| |
|
|
|
|
| |
This works on clang, but fails on GCC 4.6
llvm-svn: 283638
|
| |
|
|
| |
llvm-svn: 283636
|
| |
|
|
|
|
|
|
| |
The rest spills to the stack
Authored by Jake Goulding
llvm-svn: 283635
|
| |
|
|
|
|
|
|
|
|
| |
Once MULHS was expanded, this exposed an issue where the condition
register was thought to be 16-bit. This caused an attempt to copy a
16-bit register to an 8-bit register.
Authored by Jake Goulding
llvm-svn: 283634
|
| |
|
|
|
|
| |
This will be used in the future for disassembly.
llvm-svn: 283630
|
| |
|
|
| |
llvm-svn: 283629
|
| |
|
|
| |
llvm-svn: 283628
|
| |
|
|
| |
llvm-svn: 283627
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If heap allocation of a coroutine is elided, we need to make sure that we will update an address stored in the coroutine frame from f.destroy to f.cleanup.
Before this change, CoroSplit synthesized these stores after coro.begin:
```
store void (%f.Frame*)* @f.resume, void (%f.Frame*)** %resume.addr
store void (%f.Frame*)* @f.destroy, void (%f.Frame*)** %destroy.addr
```
In those cases where we did heap elision, but were not able to devirtualize all indirect calls, destroy call will attempt to "free" the coroutine frame stored on the stack. Oops.
Now we use select to put an appropriate coroutine subfunction in the destroy slot. As bellow:
```
store void (%f.Frame*)* @f.resume, void (%f.Frame*)** %resume.addr
%0 = select i1 %need.alloc, void (%f.Frame*)* @f.destroy, void (%f.Frame*)* @f.cleanup
store void (%f.Frame*)* %0, void (%f.Frame*)** %destroy.addr
```
Reviewers: majnemer
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D25377
llvm-svn: 283625
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This adds the AVRAsmPrinter class.
Reviewers: arsenm, kparzysz
Subscribers: llvm-commits, wdng, beanz, japaric, mgorny
Differential Revision: https://reviews.llvm.org/D25271
llvm-svn: 283623
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, tony-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D25250
llvm-svn: 283622
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tail duplication pass uses an assumed layout when making duplication
decisions. This is fine, but passes up duplication opportunities that
may arise when blocks are outlined. Because we want the updated CFG to
affect subsequent placement decisions, this change must occur during
placement.
In order to achieve this goal, TailDuplicationPass is split into a
utility class, TailDuplicator, and the pass itself. The pass delegates
nearly everything to the TailDuplicator object, except for looping over
the blocks in a function. This allows the same code to be used for tail
duplication in both places.
This change, in concert with outlining optional branches, allows
triangle shaped code to perform much better, esepecially when the
taken/untaken branches are correlated, as it creates a second spine when
the tests are small enough.
Issue from previous rollback fixed, and a new test was added for that
case as well. Issue was worklist/scheduling/taildup issue in layout.
Issue from 2nd rollback fixed, with 2 additional tests. Issue was
tail merging/loop info/tail-duplication causing issue with loops that share
a header block.
Differential revision: https://reviews.llvm.org/D18226
llvm-svn: 283619
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code used llvm basic block predecessors to decided where to insert phi
nodes. Instruction selection can and will liberally insert new machine basic
block predecessors. There is not a guaranteed one-to-one mapping from pred.
llvm basic blocks and machine basic blocks.
Therefore the current approach does not work as it assumes we can mark
predecessor machine basic block as needing a copy, and needs to know the set of
all predecessor machine basic blocks to decide when to insert phis.
Instead of computing the swifterror vregs as we select instructions, propagate
them at the end of instruction selection when the MBB CFG is complete.
When an instruction needs a swifterror vreg and we don't know the value yet,
generate a new vreg and remember this "upward exposed" use, and reconcile this
at the end of instruction selection.
This will only happen if the target supports promoting swifterror parameters to
registers and the swifterror attribute is used.
rdar://28300923
llvm-svn: 283617
|
| |
|
|
|
|
|
| |
Rename variables, simplify logic.
Not clear yet why we don't handle a target with ZeroOrNegativeOneBooleanContent too.
llvm-svn: 283613
|
| |
|
|
|
|
|
| |
This is similar to r283599, but for store instructions.
Thanks to David for pointing out!
llvm-svn: 283612
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Type visitor code had already been refactored previously to
decouple the visitor and the visitor callback interface. This
was necessary for having the flexibility to visit in different
ways (for example, dumping to yaml, reading from yaml, dumping
to ScopedPrinter, etc).
This patch merely implements the same visitation pattern for
symbol records that has already been implemented for type records.
llvm-svn: 283609
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25376
llvm-svn: 283599
|
| |
|
|
|
|
| |
We're missing at least 3 other similar folds based on what we have in InstCombine.
llvm-svn: 283596
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm, kzhuravl
Subscribers: wdng, nhaehnle, yaxunl, llvm-commits, tony-tye
Differential Revision: https://reviews.llvm.org/D25375
llvm-svn: 283593
|
| |
|
|
| |
llvm-svn: 283582
|
| |
|
|
|
|
|
|
| |
This reverts commit r283456 and reapply r282997, with explicitly
zeroing the struct member to workaround a bug in MSVC2013 with
zero-initialization: https://connect.microsoft.com/VisualStudio/feedback/details/802160
llvm-svn: 283581
|
| |
|
|
| |
llvm-svn: 283579
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we're going to canonicalize IR towards select of constants, try harder to create those.
Also, don't lose the metadata.
This is actually 4 related transforms in one patch:
// select X, (sext X), C --> select X, -1, C
// select X, (zext X), C --> select X, 1, C
// select X, C, (sext X) --> select X, C, 0
// select X, C, (zext X) --> select X, C, 0
Differential Revision: https://reviews.llvm.org/D25126
llvm-svn: 283575
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, llvm-commits, tony-tye
Differential Revision: https://reviews.llvm.org/D25366
llvm-svn: 283570
|
| |
|
|
|
|
|
|
|
| |
Partially fixes Bug 28232.
Lit tests added.
Differential Revision: https://reviews.llvm.org/D25367
llvm-svn: 283567
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: -fsample-profile needs discriminator, which will not be added if built with -g0. This patch makes sure the discriminator is added for sample-profile at -g0. A followup patch will be send out to update clang tests.
Reviewers: davidxl, dblaikie, echristo, dnovillo
Subscribers: mehdi_amini, probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D25132
llvm-svn: 283565
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, we marked the branch conditions of latch blocks uniform after
vectorization if they were instructions contained in the loop. However, if a
condition instruction has users other than the branch, it may not remain
uniform. This patch ensures the conditions we mark uniform are only used by the
branch. This should fix PR30627.
Reference: https://llvm.org/bugs/show_bug.cgi?id=30627
llvm-svn: 283563
|
| |
|
|
| |
llvm-svn: 283561
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to AMDGPUBaseInfo.h
Reviewers: artem.tamazov, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D25084
llvm-svn: 283560
|
| |
|
|
| |
llvm-svn: 283558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
While walking defs of pointer operands we were assuming that the pointer
size would remain constant. This is not true, because addresspacecast
instructions may cast the pointer to an address space with a different
pointer width.
This partial reverts r282612, which was a more conservative solution
to this problem.
Reviewers: reames, sanjoy, apilipenko
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D24772
llvm-svn: 283557
|