| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Requesting DWARF v5 will now get you the new compile-unit and
type-unit headers. llvm-dwarfdump will also recognize them.
Differential Revision: http://reviews.llvm.org/D30206
llvm-svn: 296514
|
|
|
|
| |
llvm-svn: 296513
|
|
|
|
|
|
|
|
|
| |
It's not clear to me if this is always better than
doing ds_write2_b64 This adds the constraint of
a 128-bit register input instead of a pair of
64-bit.
llvm-svn: 296512
|
|
|
|
| |
llvm-svn: 296511
|
|
|
|
|
|
| |
We converted them before, but there were a few remaining occurrences.
llvm-svn: 296510
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30348
llvm-svn: 296508
|
|
|
|
| |
llvm-svn: 296507
|
|
|
|
|
|
|
|
|
|
|
| |
If during scheduling we have identified that we cannot keep optimistic
occupancy increase critical register pressure limit and try scheduling
of the whole function again. In this case blocks with smaller pressure
will have a chance for better scheduling.
Differential Revision: https://reviews.llvm.org/D30442
llvm-svn: 296506
|
|
|
|
|
|
|
|
|
|
| |
I do not fully understand why we had these values in the tests, but
the new value matches what ld.bfd and ld.gold set, so I guess that
was just a mistake.
Differential Revision: https://reviews.llvm.org/D30441
llvm-svn: 296505
|
|
|
|
|
|
| |
<rdar://problem/30735021>
llvm-svn: 296504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r296378.
I am pretty sure this is incorrect. In particular, for just
.cfi_startproc
nop
.cfi_endproc
We now add an extra 4 zeros that neither bfd nor gold add.
llvm-svn: 296503
|
|
|
|
| |
llvm-svn: 296502
|
|
|
|
| |
llvm-svn: 296501
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30434
llvm-svn: 296500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
public enum VeryLongEnum {
ENUM_WITH_MANY_PARAMETERS("aaaaaaaaaaaaaaaaaaaaaa",
"bbbbbbbbbbbbbbbbbbbbbbbbbbb",
"ccccccccccccccccccc")
,
SECOND_ENUM("a", "b", "c");
private VeryLongEnum(String a, String b, String c) {}
}
After:
public enum VeryLongEnum {
ENUM_WITH_MANY_PARAMETERS("aaaaaaaaaaaaaaaaaaaaaa",
"bbbbbbbbbbbbbbbbbbbbbbbbbbb",
"ccccccccccccccccccc") ,
SECOND_ENUM("a", "b", "c");
private VeryLongEnum(String a, String b, String c) {}
}
llvm-svn: 296499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: For SamplePGO, the profile may contain cross-module inline stacks. As we need to make sure the profile annotation happens when all the hot inline stacks are expanded, we need to pass this info to the module importer so that it can import proper functions if necessary. This patch implemented this feature by emitting cross-module targets as part of function entry metadata. In the module-summary phase, the metadata is used to build call edges that points to functions need to be imported.
Reviewers: mehdi_amini, tejohnson
Reviewed By: tejohnson
Subscribers: davidxl, llvm-commits
Differential Revision: https://reviews.llvm.org/D30053
llvm-svn: 296498
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC appears to be getting confused as to whether OverloadToken is
supposed to be public or not.
This was discovered by code in Swift, and has been reported to
microsoft by hughbe:
https://connect.microsoft.com/VisualStudio/feedback/details/3116517
Differential Revision: https://reviews.llvm.org/D29880
llvm-svn: 296497
|
|
|
|
| |
llvm-svn: 296496
|
|
|
|
|
|
| |
This had broken as the result of some previous cleanup.
llvm-svn: 296495
|
|
|
|
|
|
|
| |
This migrates the stream code away from MSFError to using its
own custom Error class.
llvm-svn: 296494
|
|
|
|
| |
llvm-svn: 296493
|
|
|
|
| |
llvm-svn: 296492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces new method to estimate register pressure in
GCNScheduler. Standard RPTracker gives huge error due to the following
reasons:
1. It does not account for live-ins or live-outs if value is not used
in the region itself. That creates a huge error in a very common case
if there are a lot of live-thu registers.
2. It does not properly count subregs.
3. It assumes a register used as an input operand can be reused as an
output. This is not always possible by itself, this is not what RA
will finally do in many cases for various reasons not limited to RA's
inability to do so, and this is not so if the value is actually a
live-thu.
In addition we can now see clear separation between live-in pressure
which we cannot change with the scheduling and tentative pressure
which we can change.
Differential Revision: https://reviews.llvm.org/D30439
llvm-svn: 296491
|
|
|
|
|
|
|
|
| |
along gnueabi as this matches both gcc and what the kernel expects.
More of PR27311
llvm-svn: 296490
|
|
|
|
|
|
|
|
| |
- We do emit amd_kernel_code_t v1.1
Differential Revision: https://reviews.llvm.org/D30433
llvm-svn: 296489
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LLVM backend cannot produce any debug info for an llvm::Function
without a DISubprogram attachment. When inlining a debug-info-carrying
function into a nodebug function, there is therefore no reason to keep
any debug info intrinsic calls or debug locations on the instructions.
This fixes a problem discovered in PR32042.
rdar://problem/30679307
llvm-svn: 296488
|
|
|
|
| |
llvm-svn: 296487
|
|
|
|
|
|
|
|
| |
intermediate nodes have a single use across all results not just the result that was used to reach the chain node.
This recovers a test case that was severely broken by r296476, my making sure we don't create ADD/ADC that loads and stores when there is also a flag dependency.
llvm-svn: 296486
|
|
|
|
|
|
|
|
|
|
|
| |
- remove path to dts-1.x (corresponds to gcc 4.7)
- add path to dts-6 (corresponds to 6.x)
Patch By: Maria Gottschalk
Differential Revision: https://reviews.llvm.org/D29855
llvm-svn: 296485
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|