| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If two subregs of the same register are defined and we need to revert
schedule changing def order, we will end up with both instructions
having def,read-undef flags because adjustLaneLiveness() will only set
this flag but will not remove it.
Fix this by removing read-undef flags before calling adjustLaneLiveness.
Differential Revision: https://reviews.llvm.org/D30428
llvm-svn: 296484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
applied to a function
Stack Smash Protection is not completely free, so in hot code, the overhead it causes can cause performance issues. By adding diagnostic information for which functions have SSP and why, a user can quickly determine what they can do to stop SSP being applied to a specific hot function.
This change adds a remark that is reported by the stack protection code when an instruction or attribute is encountered that causes SSP to be applied.
Patch by: James Henderson
Differential Revision: https://reviews.llvm.org/D29023
llvm-svn: 296483
|
|
|
|
|
|
|
|
|
|
| |
Patch By: Alexander Richardson
Reviewers: atanasyan, theraven, sdardis
Differential Revision: https://reviews.llvm.org/D30330
llvm-svn: 296482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The false positive happens on two neighbour CXXDefaultArgExpr AST nodes.
like below:
```
CXXFunctionalCastExpr 0x85c9670 <col:7, col:23> 'struct ZZ' functional cast to struct ZZ <ConstructorConversion>
`-CXXConstructExpr 0x85c9518 <col:7, col:23> 'struct ZZ' 'void (uint64, const uint64 *)'
|-CallExpr 0x85a0a90 <col:10, col:22> 'uint64':'unsigned long long'
| |-ImplicitCastExpr 0x85a0a78 <col:10> 'uint64 (*)(uint64)' <FunctionToPointerDecay>
| | `-DeclRefExpr 0x85a09f0 <col:10> 'uint64 (uint64)' lvalue Function 0x85a06a0 'Hash' 'uint64 (uint64)'
| `-CXXDefaultArgExpr 0x85a0ac8 <<invalid sloc>> 'uint64':'unsigned long long'
`-CXXDefaultArgExpr 0x85c94f8 <<invalid sloc>> 'const uint64 *'
```
For each particular CXXDefaultArgExpr node, we need to reset
FirstSubExpr, otherwise FirstSubExpr will refer to an incorrect expr.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D30412
llvm-svn: 296479
|
|
|
|
|
|
|
|
| |
subclass that knows how to generate it.
There's a circular dependency that's only revealed when LLVM_ENABLE_MODULES=1.
llvm-svn: 296478
|
|
|
|
|
|
|
|
| |
are used
Differential Revision: https://reviews.llvm.org/D30192
llvm-svn: 296477
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
enabled.
Recommiting after fixup of 32-bit aliasing sign offset bug in DAGCombiner.
* Simplify Consecutive Merge Store Candidate Search
Now that address aliasing is much less conservative, push through
simplified store merging search and chain alias analysis which only
checks for parallel stores through the chain subgraph. This is cleaner
as the separation of non-interfering loads/stores from the
store-merging logic.
When merging stores search up the chain through a single load, and
finds all possible stores by looking down from through a load and a
TokenFactor to all stores visited.
This improves the quality of the output SelectionDAG and the output
Codegen (save perhaps for some ARM cases where we correctly constructs
wider loads, but then promotes them to float operations which appear
but requires more expensive constant generation).
Some minor peephole optimizations to deal with improved SubDAG shapes (listed below)
Additional Minor Changes:
1. Finishes removing unused AliasLoad code
2. Unifies the chain aggregation in the merged stores across code
paths
3. Re-add the Store node to the worklist after calling
SimplifyDemandedBits.
4. Increase GatherAllAliasesMaxDepth from 6 to 18. That number is
arbitrary, but seems sufficient to not cause regressions in
tests.
5. Remove Chain dependencies of Memory operations on CopyfromReg
nodes as these are captured by data dependence
6. Forward loads-store values through tokenfactors containing
{CopyToReg,CopyFromReg} Values.
7. Peephole to convert buildvector of extract_vector_elt to
extract_subvector if possible (see
CodeGen/AArch64/store-merge.ll)
8. Store merging for the ARM target is restricted to 32-bit as
some in some contexts invalid 64-bit operations are being
generated. This can be removed once appropriate checks are
added.
This finishes the change Matt Arsenault started in r246307 and
jyknight's original patch.
Many tests required some changes as memory operations are now
reorderable, improving load-store forwarding. One test in
particular is worth noting:
CodeGen/PowerPC/ppc64-align-long-double.ll - Improved load-store
forwarding converts a load-store pair into a parallel store and
a memory-realized bitcast of the same value. However, because we
lose the sharing of the explicit and implicit store values we
must create another local store. A similar transformation
happens before SelectionDAG as well.
Reviewers: arsenm, hfinkel, tstellarAMD, jyknight, nhaehnle
llvm-svn: 296476
|
|
|
|
|
|
|
| |
It does not make sense. Them added either to
Out::BssRelRo or Out::Bss, which are always RW.
llvm-svn: 296475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 296474
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lower i32, float and double parameters that need to live on the stack. This
boils down to creating some G_GEPs starting from the stack pointer and storing
the values there. During the process we also keep track of the stack size and
use the final value in the ADJCALLSTACKDOWN/UP instructions.
We currently assert for smaller types, since they usually require extensions.
They will be handled in a separate patch.
llvm-svn: 296473
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: Eugene.Zelenko
Tags: #clang-tools-extra
Patch by Peter Szecsi!
Differential Revision: https://reviews.llvm.org/D24137
llvm-svn: 296472
|
|
|
|
|
|
| |
Put it into a register by means of a MOVi.
llvm-svn: 296471
|
|
|
|
| |
llvm-svn: 296470
|
|
|
|
|
|
|
| |
Like G_FRAME_INDEX, G_CONSTANT has one register operand and one non-register
operand.
llvm-svn: 296469
|
|
|
|
| |
llvm-svn: 296468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also limits the blacklisting to only apply when the tag is actually
followed by a parameter in curly braces.
/** @mods {long.type.must.not.wrap} */
vs
/** @const this is a long description that may wrap. */
Reviewers: djasper
Subscribers: klimek, krasimir, cfe-commits
Differential Revision: https://reviews.llvm.org/D30452
llvm-svn: 296467
|
|
|
|
|
|
| |
We do not use it later, so don't have to store.
llvm-svn: 296466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
clang adds !srcloc metadata to inline assembly in LLVM bitcode generated
for inline assembly in C. The value of this !srcloc is passed to the
diagnostics handler if the inline assembly generates a diagnostic.
clang is able to turn this cookie back to a location in the C source
file.
To test this functionality without a dependency, make llc print the
!srcloc metadata if it is present. The added test uses this mechanism
to test that the correct !srclocs are passed to the diag handler.
Reviewers: rengolin, rnk, echristo, grosbach, mehdi_amini
Reviewed By: mehdi_amini
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D30167
llvm-svn: 296465
|
|
|
|
| |
llvm-svn: 296464
|
|
|
|
|
|
|
|
| |
registered as permanent libraries."
It broke clang/test/Analysis/checker-plugins.c
llvm-svn: 296463
|
|
|
|
|
|
| |
At this point, G_GEP is just an add, so we treat it exactly like a G_ADD.
llvm-svn: 296462
|
|
|
|
|
|
| |
SymbolInfo::Signals.
llvm-svn: 296461
|
|
|
|
|
|
| |
MSYS' tools don't do globbing.
llvm-svn: 296460
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Thumb2, instructions which write to the PC are UNPREDICTABLE if they are in
an IT block but not the last instruction in the block.
Previously, we only diagnosed this for LDM instructions, this patch extends the
diagnostic to cover all of the relevant instructions.
Differential Revision: https://reviews.llvm.org/D30398
llvm-svn: 296459
|
|
|
|
| |
llvm-svn: 296458
|
|
|
|
|
|
|
| |
It checked name from one symbol and other
data from another before.
llvm-svn: 296457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this simplification for a loop nest:
void foo(long n1_a, long n1_b, long n1_c, long n1_d,
long p1_b, long p1_c, long p1_d,
float A_1[][p1_b][p1_c][p1_d]) {
for (long i = 0; i < n1_a; i++)
for (long j = 0; j < n1_b; j++)
for (long k = 0; k < n1_c; k++)
for (long l = 0; l < n1_d; l++)
A_1[i][j][k][l] += i + j + k + l;
}
the assumption:
n1_a <= 0 or (n1_a > 0 and n1_b <= 0) or
(n1_a > 0 and n1_b > 0 and n1_c <= 0) or
(n1_a > 0 and n1_b > 0 and n1_c > 0 and n1_d <= 0) or
(n1_a > 0 and n1_b > 0 and n1_c > 0 and n1_d > 0 and
p1_b >= n1_b and p1_c >= n1_c and p1_d >= n1_d)
is taken rather than the simpler assumption:
p9_b >= n9_b and p9_c >= n9_c and p9_d >= n9_d.
The former is less strict, as it allows arbitrary values of p1_* in case, the
loop is not executed at all. However, in practice these precise constraints
explode when combined across different accesses and loops. For now it seems
to make more sense to take less precise, but more scalable constraints by
default. In case we find a practical example where more precise constraints
are needed, we can think about allowing such precise constraints in specific
situations where they help.
This change speeds up the new test case from taking very long (waited at least
a minute, but it probably takes a lot more) to below a second.
llvm-svn: 296456
|
|
|
|
|
|
| |
This should be the same as the mapping for G_ADD etc.
llvm-svn: 296455
|
|
|
|
|
|
|
|
|
|
|
| |
The option -mexecute-only is translated into the backend option
-arm-execute-only. But this option only makes sense for the compiler and
the assembler does not recognize it. This patch stops clang from passing
this option to the assembler.
Change-Id: I4f4cb1162c13cfd50a0a36702a4ecab1bc0324ba
Review: https://reviews.llvm.org/D30414
llvm-svn: 296454
|
|
|
|
|
|
|
|
|
| |
The begining command "rm" will return 1 when there is not such file to
delete.
This patch is to remove it, as it's not needed for the test.
llvm-svn: 296453
|
|
|
|
|
|
|
| |
At the moment we're only interested in GEPs for putting call parameters on the
stack, so we'll stick to 32-bit offsets.
llvm-svn: 296452
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are many special cases and a layer of abstraction or two in the
way, but the VA calculation in the typical case is actually very simple
and probably makes perfect sense even to somebody new to linkers.
Also, this line brings together many components and is a good place to
start understanding the linker (or improve one's existing
understanding).
llvm-svn: 296451
|
|
|
|
| |
llvm-svn: 296450
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use a common definition of a "this variable is unused" annotation for useless
variables only present for their lambda global initializers, to silence gcc's
warning.
Reviewers: dberris
Reviewed By: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29860
llvm-svn: 296449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Naively it seemed at first like getVA had the responsibility of adding
the addend, and getSymVA had the responsibility of getting the symbol
VA.
So it was not obvious to me at first why getVA passes Addend to
getSymVA. In fact, it passes it as a mutable reference.
It turns out that it only matters for SHF_MERGE sections, and in
particular only for STT_SECTION symbols that are used as a hack for
reducing the number of local symbols (e.g. to avoid a local symbol for
each string in the string table).
llvm-svn: 296448
|
|
|
|
| |
llvm-svn: 296447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add usage count to find-all-symbols.
FindAllSymbols now finds (most!) main-file usages of the discovered symbols.
The per-TU map output has NumUses=0 or 1 (only one use per file is counted).
The reducer aggregates these to find the number of files that use a symbol.
The NumOccurrences is now set to 1 in the mapper rather than being inferred by
the reducer, for consistency.
The idea here is to use NumUses for ranking: intuitively number of files that
use a symbol is more meaningful than number of files that include the header.
Reviewers: hokein, bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30210
llvm-svn: 296446
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, we assume that applications built with XRay would like to
have the instrumentation sleds patched before main starts. This patch
changes the default so that we do not patch the instrumentation sleds
before main. This default is more helpful for deploying applications in
environments where changing the current default is harder (i.e. on
remote machines, or work-pool-like systems).
This default (not to patch pre-main) makes it easier to selectively run
applications with XRay instrumentation enabled, than with the current
state.
Reviewers: echristo, timshen
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D30396
llvm-svn: 296445
|
|
|
|
|
|
|
| |
These were noticed as missing in a code review. Add them and the boring
unit test to make sure they compile and DTRT.
llvm-svn: 296444
|
|
|
|
| |
llvm-svn: 296443
|
|
|
|
|
|
|
|
|
|
| |
This is also useful in cases when llvm is in a shared library. First we dlopen
the llvm shared library and then we register it as a permanent library in order
to keep the JIT and other services working.
Patch reviewed by Vedant Kumar (D29955)!
llvm-svn: 296442
|
|
|
|
|
|
| |
This is a normal maintenance update.
llvm-svn: 296441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With this change ImplicitNullCheck optimization uses alias analysis
and can use load/store memory access for implicit null check if there
are other load/store before but memory accesses do not alias.
Patch by Serguei Katkov!
Reviewers: sanjoy
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30331
llvm-svn: 296440
|
|
|
|
|
|
|
|
|
|
|
| |
In other places in LLD, we use write32<E> instead of Elf_Word.
This patch uses the same technique in the hash table classes.
The hash table classes needs improving as they have almost no
comments. We at least need to describe the hash table structure
and why we have to support two different on-disk hash tables
for the same purpose. I'll do that later.
llvm-svn: 296439
|
|
|
|
| |
llvm-svn: 296438
|
|
|
|
| |
llvm-svn: 296437
|
|
|
|
|
|
| |
These assignments seem meaningful, but actually all tests pass without them.
llvm-svn: 296436
|
|
|
|
|
|
|
|
| |
Previously, these two functions put their symbols in different queues.
Now that the queues have been merged. So there's no point to keep two
separate functions.
llvm-svn: 296435
|
|
|
|
| |
llvm-svn: 296434
|
|
|
|
|
|
|
|
|
| |
That function doesn't use any member of SymbolTableSection, so I
couldn't see a reason to make it a member of that class. The function
takes a SymbolBody, so it is more natural to make it a member of
SymbolBody.
llvm-svn: 296433
|