| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the code used getActiveBits() to determine the highest set
bit of each APInt first. However doing so requires the same amount of
memory accesses as simply comparing both numbers right away.
Removing all the active bit checks leads to simpler code and is faster
in my benchmark.
Differential Revision: http://reviews.llvm.org/D16620
llvm-svn: 260447
|
| |
|
|
|
|
|
|
|
|
|
| |
This restores commit r260408, along with a fix for a bot failure.
The bot failure was caused by dereferencing a unique_ptr in the same
call instruction parameter list where it was passed via std::move.
Apparently due to luck this was not exposed when I built the compiler
with clang, only with gcc.
llvm-svn: 260442
|
| |
|
|
|
|
|
|
|
|
| |
There's nothing preventing callers of LVI from asking for lattice values representing a Constant. In fact, given that several callers are walking back through PHI nodes and trying to simplify predicates, such queries are actually quite common. This is mostly harmless today, but we start volatiling assertions if we add new calls to getBlockValue in otherwise reasonable places.
Note that this change is not NFC. Specifically:
1) The result returned through getValueAt will now be more precise. In principle, this could trigger any latent infinite optimization loops in callers, but in practice, we're unlikely to see this.
2) The result returned through getBlockValueAt is potentially weakened for non-constants that were previously queried. With the old code, you had the possibility that a later query might bypass the cache and discover some information the original query did not. I can't find a scenario which actually causes this to happen, but it was in principle possible. On the other hand, this may end up reducing compile time when the same value is queried repeatedly.
llvm-svn: 260439
|
| |
|
|
| |
llvm-svn: 260438
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Refactor common value, scope, and label tracking logic out of DwarfDebug
into a common base class called DebugHandlerBase.
Update an old LLVM IR test case to avoid an assertion in LexicalScopes.
Reviewers: dblaikie, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16931
llvm-svn: 260432
|
| |
|
|
| |
llvm-svn: 260429
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a crash where subsequent spills would be unable to scavenge
a register. In particular, it fixes a crash in piglit's
spec@glsl-1.50@execution@geometry@max-input-components (the test still
has a shader that fails to compile because of too many SGPR spills, but
at least it doesn't crash any more).
This is a candidate for the release branch.
Reviewers: arsenm, tstellarAMD
Subscribers: qcolombet, arsenm
Differential Revision: http://reviews.llvm.org/D16558
llvm-svn: 260427
|
| |
|
|
| |
llvm-svn: 260426
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of passing varargs directly on the user stack, allocate a buffer in
the caller's stack frame and pass a pointer to it. This simplifies the C
ABI (e.g. non-C callers of C functions do not need to use C's user stack if
they have their own mechanism) and allows further optimizations in the future
(e.g. fewer functions may need to use the stack).
Differential Revision: http://reviews.llvm.org/D17048
llvm-svn: 260421
|
| |
|
|
| |
llvm-svn: 260419
|
| |
|
|
|
|
| |
This reverts commit r260408. Bot failure that I need to investigate.
llvm-svn: 260412
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch uses the lower 64-bits of the MD5 hash of a function name as
a GUID in the function index, instead of storing function names. Any
local functions are first given a global name by prepending the original
source file name. This is the same naming scheme and GUID used by PGO in
the indexed profile format.
This change has a couple of benefits. The primary benefit is size
reduction in the combined index file, for example 483.xalancbmk's
combined index file was reduced by around 70%. It should also result in
memory savings for the index file in memory, as the in-memory map is
also indexed by the hash instead of the string.
Second, this enables integration with indirect call promotion, since the
indirect call profile targets are recorded using the same global naming
convention and hash. This will enable the function importer to easily
locate function summaries for indirect call profile targets to enable
their import and subsequent promotion.
The original source file name is recorded in the bitcode in a new
module-level record for use in the ThinLTO backend pipeline.
Reviewers: davidxl, joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17028
llvm-svn: 260408
|
| |
|
|
| |
llvm-svn: 260406
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17038
llvm-svn: 260401
|
| |
|
|
|
|
|
|
|
|
| |
This patch reads the indirect-call value records in the profile and makes the
annotation in the indirect-call instruction. This is for IR level profile
instrumentation.
Differential Revision: http://reviews.llvm.org/D16935
llvm-svn: 260400
|
| |
|
|
| |
llvm-svn: 260399
|
| |
|
|
|
|
|
| |
These weren't actually sharing anything in the common
LowerLOAD.
llvm-svn: 260398
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed on IRC, move the ThinLTOGlobalProcessing code out of
the linker, and into TransformUtils. The name of the class is changed
to FunctionImportGlobalProcessing.
Reviewers: joker.eph, rafael
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D17081
llvm-svn: 260395
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The encodings for floating point conditions A(lways) and N(ever) were
incorrectly specified for the assembly parser, per Sparc manual v8 page
121. This change corrects that mistake.
Also, strangely, all of the branch instructions already had MC test
cases, except for the broken ones. Added the tests.
Patch by Chris Dewhurst
Differential Revision: http://reviews.llvm.org/D17074
llvm-svn: 260390
|
| |
|
|
| |
llvm-svn: 260389
|
| |
|
|
| |
llvm-svn: 260387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch uses one bit in profile version to differentiate Clang
instrumentation and IR level instrumentation profiles.
PGOInstrumenation generates a COMDAT variable __llvm_profile_raw_version so
that the compiler runtime can set the right profile kind.
For Maco-O platform, we generate the variable as linkonce_odr linkage as
COMDAT is not supported.
PGOInstrumenation now checks this bit to make sure it's an IR level
instrumentation profile.
The patch was submitted as r260164 but reverted due to a Darwin test breakage.
Original Differential Revision: http://reviews.llvm.org/D15540
Differential Revision: http://reviews.llvm.org/D17020
llvm-svn: 260385
|
| |
|
|
| |
llvm-svn: 260383
|
| |
|
|
| |
llvm-svn: 260382
|
| |
|
|
|
|
|
|
| |
This patch fixes stack alignments for MCU (should be aligned to 4 bytes).
Differential Revision: http://reviews.llvm.org/D15646
llvm-svn: 260375
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add the AVR instruction tablegen definitions.
Reviewers: stoklund, hfinkel, dsanders, arsenm, vkalintiris
Subscribers: dylanmckay, agnat, rjordans, llvm-commits
Differential Revision: http://reviews.llvm.org/D15703
llvm-svn: 260363
|
| |
|
|
| |
llvm-svn: 260359
|
| |
|
|
|
|
| |
This should fix some random bot failures caused by r260336.
llvm-svn: 260342
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch adds a new class, OrcI386, which contains the hooks needed to
support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT
re-entry code uses the FXSAVE/FXRSTOR instructions).
Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and
regression and unit tests are enabled for this architecture.
llvm-svn: 260338
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Tests for this will be added once the AMDGPU backend enables this
option.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16602
llvm-svn: 260336
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. This also include extra support for insertvalue and extracvalue.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17055
llvm-svn: 260335
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instruction from the C API.
Summary: As per title. This remove the need to rely on internal knowledge of call and invoke instruction to find called value and argument count.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Differential Revision: http://reviews.llvm.org/D17054
llvm-svn: 260332
|
| |
|
|
|
|
|
| |
This is the load counterpart to the store optimization that was added in:
http://reviews.llvm.org/rL260145
llvm-svn: 260325
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Remove the convergent attribute on any functions which provably do not
contain or invoke any convergent functions.
After this change, we'll be able to modify clang to conservatively add
'convergent' to all functions when compiling CUDA.
Reviewers: jingyue, joker.eph
Subscribers: llvm-commits, tra, jhen, hfinkel, resistor, chandlerc, arsenm
Differential Revision: http://reviews.llvm.org/D17013
llvm-svn: 260319
|
| |
|
|
| |
llvm-svn: 260317
|
| |
|
|
| |
llvm-svn: 260316
|
| |
|
|
|
|
|
| |
Using Op makes it look like we're doing something with it.
We're really not.
llvm-svn: 260315
|
| |
|
|
| |
llvm-svn: 260314
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Comes with an awesome test.
Depends on D16912
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16942
llvm-svn: 260313
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass implements whole program optimization of virtual calls in cases
where we know (via bitset information) that the list of callees is fixed. This
includes the following:
- Single implementation devirtualization: if a virtual call has a single
possible callee, replace all calls with a direct call to that callee.
- Virtual constant propagation: if the virtual function's return type is an
integer <=64 bits and all possible callees are readnone, for each class and
each list of constant arguments: evaluate the function, store the return
value alongside the virtual table, and rewrite each virtual call as a load
from the virtual table.
- Uniform return value optimization: if the conditions for virtual constant
propagation hold and each function returns the same constant value, replace
each virtual call with that constant.
- Unique return value optimization for i1 return values: if the conditions
for virtual constant propagation hold and a single vtable's function
returns 0, or a single vtable's function returns 1, replace each virtual
call with a comparison of the vptr against that vtable's address.
Differential Revision: http://reviews.llvm.org/D16795
llvm-svn: 260312
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. Also add a facility method to get the name of a basic block from the C API.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16912
llvm-svn: 260309
|
| |
|
|
|
|
|
|
|
| |
Now the parser supports `%got(sym)` expressions only but `%got(sym + const)`
variant is also valid and accepted by GAS.
Differential Revision: http://reviews.llvm.org/D16885
llvm-svn: 260305
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`hasNoAliasAttr` is buggy: it checks to see if the called function has
a `noalias` attribute, which is incorrect since functions are not even
allowed to have the `noalias` attribute. The comment on its only
caller, `llvm::isNoAliasFn`, makes it pretty clear that the intention
to do the `noalias` check on the return value, and not the callee.
Unfortunately I couldn't find a way to test this upstream -- fixing
this does not change the observable behavior of any of the passes that
use this. This is not very surprising, since `noalias` does not tell
anything about the contents of the allocated memory (so, e.g., you
still cannot fold loads). I'll be happy to be proven wrong though.
Reviewers: chandlerc, reames
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17037
llvm-svn: 260298
|
| |
|
|
|
|
| |
While trying to track down what appears to be a LoopVectorizer bug, I noticed that we had no validation of the correctness of calls emitted to @llvm.masked.load and @llvm.masked.store. This meant malformed IR was showing up much much later than it should. Hopefully, having Verifier rules in place will make this easier to isolate.
llvm-svn: 260296
|
| |
|
|
|
|
|
|
|
| |
I reinvented this functionality in http://reviews.llvm.org/D16828 because it was
hidden away as a static function. The changes in x86 are not based on a complete
audit. I suspect there are other possible uses there, and there are almost certainly
more potential users in other targets.
llvm-svn: 260295
|
| |
|
|
| |
llvm-svn: 260283
|
| |
|
|
|
|
|
|
| |
We introduced gc.relocates of vector-of-pointer types a couple of weeks back. Somehow, I missed updating the InstCombine rule to account for this. If we hit this code path with a vector-of-pointers gc.relocate, we'd crash on a cast<PointerType>.
I also took the chance to do a bit of code style cleanup.
llvm-svn: 260279
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix case where a pre-inc/dec load/store would not be formed if the
add/sub that forms the inc/dec part of the operation was the first
instruction in the block being examined.
Reviewers: mcrosier, jmolloy, t.p.northover, junbuml
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16785
llvm-svn: 260275
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 260274
|
| |
|
|
| |
llvm-svn: 260273
|