| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
I messed up the diff.
llvm-svn: 319429
|
| |
|
|
|
|
|
| |
Fallback if we have a byval parameter or argument since we don't support
them yet.
llvm-svn: 319428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the unification of the debug format and the MIR format, avoid
printing "vreg" for virtual registers (which is one of the current MIR
possibilities).
Basically:
* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E "s/%vreg([0-9]+)/%\1/g"
* grep -nr '%vreg' . and fix if needed
* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E "s/ vreg([0-9]+)/ %\1/g"
* grep -nr 'vreg[0-9]\+' . and fix if needed
Differential Revision: https://reviews.llvm.org/D40420
llvm-svn: 319427
|
| |
|
|
| |
llvm-svn: 319424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Original RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html
I wasn't sure who to put as reviewers, so please add/remove people as appropriate.
This change adds a '.stack-size' section containing metadata on function stack sizes to output ELF files behind the new -stack-size-section flag. The section contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128).
The contents of this section can be used to measure changes to stack sizes between different versions of the compiler or a source base. The advantage of having a section is that we can extract this information when examining binaries that we didn't build, and it allows users and tools easy access to that information just by referencing the binary.
There is a follow up change to add an option to clang.
Thanks.
Reviewers: hfinkel, MatzeB
Reviewed By: MatzeB
Subscribers: thegameg, asb, llvm-commits
Differential Revision: https://reviews.llvm.org/D39788
llvm-svn: 319423
|
| |
|
|
|
|
|
|
|
|
| |
visitAND attempts to narrow the width of extending loads that are
then masked off. ReduceLoadWidth already exists for a similar purpose
and handles shifts, so I've moved the code to handle AND nodes there.
Differential Revision: https://reviews.llvm.org/D39595
llvm-svn: 319421
|
| |
|
|
| |
llvm-svn: 319419
|
| |
|
|
| |
llvm-svn: 319418
|
| |
|
|
|
|
| |
Should fix build failure introduced by r319416 on non-darwin hosts.
llvm-svn: 319417
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements `getBundleInfo`, which uses CoreFoundation to
obtain information about the CFBundle. This information is needed to
populate the Plist in the dSYM bundle.
This change only applies to darwin and is an NFC as far as other
platforms are concerned.
Differential revision: https://reviews.llvm.org/D40244
llvm-svn: 319416
|
| |
|
|
|
|
| |
This reverts commit rL319407 due to failures in some buildbot.
llvm-svn: 319410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Csmith generated a program where a store after load to the same address did
not get chained after the new load created during DAG legalizing, and so
performed an illegal overwrite of the expected value.
When the new zero-extending load is created, the chain users of the original
load must be updated, which was not done previously.
A similar case was also found and handled in lowerBITCAST.
Review: Ulrich Weigand
https://reviews.llvm.org/D40542
llvm-svn: 319409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, SROA splits loads and stores only when they are accessing the whole alloca.
This patch relaxes this limitation to allow splitting a load/store if all other loads and stores to the alloca are disjoint to or fully included in the current load/store. If there is no other load or store that crosses the boundary of the current load/store, the current splitting implementation works as is.
The whole-alloca loads and stores meet this new condition and so they are still splittable.
Here is a simplified motivating example.
struct record {
long long a;
int b;
int c;
};
int func(struct record r) {
for (int i = 0; i < r.c; i++)
r.b++;
return r.b;
}
When updating r.b (or r.c as well), LLVM generates redundant instructions on some platforms (such as x86_64, ppc64); here, r.b and r.c are packed into one 64-bit GPR when the struct is passed as a method argument.
With this patch, the above example is compiled into only few instructions without loop.
Without the patch, unnecessary loop-carried dependency is introduced by SROA and the loop cannot be eliminated by the later optimizers.
Differential Revision: https://reviews.llvm.org/D32998
llvm-svn: 319407
|
| |
|
|
|
|
| |
Normal type legalization will widen everything. This requires forcing 0s into the mask register. We can instead choose the form that only reads 2 elements without zeroing the mask.
llvm-svn: 319406
|
| |
|
|
|
|
| |
We don't use k-registers and instead use the MSB so we need to make sure we sign extend the mask to the msb.
llvm-svn: 319405
|
| |
|
|
|
|
|
|
|
| |
We've recently changed the default for `xray_naive_log=` to be `false`
instead of `true` to make it more consistent with the FDR mode logging
implementation. This means we will now ask users to explicitly choose
which version of the XRay logging is being used.
llvm-svn: 319400
|
| |
|
|
|
|
| |
- Added lit testcases that were supposed to be part of r319398
llvm-svn: 319399
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the inline candidate function. This contrasts with the scheme of keeping only the 'early return' portion of the inline candidate and outlining the rest of the function as a single function call.
Support for outlining multiple regions of each function is added, as well as some basic heuristics to determine which regions are good to outline. Outline candidates limited to regions that are single-entry & single-exit. We also avoid outlining regions that produce live-exit variables, which may inhibit some forms of code motion (like commoning).
Fallback to the regular partial inlining scheme is retained when either i) no regions are identified for outlining in the function, or ii) the outlined function could not be inlined in any of its callers.
Differential Revision: https://reviews.llvm.org/D38190
llvm-svn: 319398
|
| |
|
|
| |
llvm-svn: 319397
|
| |
|
|
|
|
|
|
| |
GFX9 does not enable bounds checking for the resource descriptors
used for private access, so it should be OK to use vaddr with
a potentially negative value.
llvm-svn: 319393
|
| |
|
|
|
|
|
|
| |
While the ArrayRef can technically have unaligned data, it would be
extremely surprising if iterating over it caused undefined behavior
when a reference to the underlying type was bound.
llvm-svn: 319392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix for the coverage segment builder.
If multiple regions must be popped off the active stack at once, and
more than one of them end at the same location, emit a segment using the
count from the most-recent completed region.
Fixes PR35437, rdar://35760630
Testing: invoked llvm-cov on a stage2 build of clang, additional unit
tests, check-profile
llvm-svn: 319391
|
| |
|
|
| |
llvm-svn: 319390
|
| |
|
|
| |
llvm-svn: 319387
|
| |
|
|
|
|
|
|
|
|
| |
a VZEXT to create a larger VSEXT.
If the input the vzext was signed this would do the wrong thing.
Not sure how to test this.
llvm-svn: 319382
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- add -ppc-reg-with-percent-prefix option to use %r3 etc as register
names
- split off logic for Darwinish verbose conditional codes into a helper
function
- be explicit about Darwin vs AIX vs GNUish assembler flavors
Based on the patch from Alexandre Yukio Yamashita
Differential Revision: https://reviews.llvm.org/D39016
llvm-svn: 319381
|
| |
|
|
|
|
|
|
|
| |
I believe these were recently fixed by:
https://reviews.llvm.org/rL319186
Differential Revision: https://reviews.llvm.org/D40619
llvm-svn: 319380
|
| |
|
|
|
|
|
|
|
|
|
| |
This class had some code that would automatically remap type
indices before hashing and serializing. The only caller of
this method was the TypeStreamMerger anyway, and the method
doesn't make general sense, and prevents making certain future
improvements to the class. So, factoring this up one level
into the TypeStreamMerger where it belongs.
llvm-svn: 319377
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to insert an assertsext/assertzext based on the original type
If we put in an assertsext/zext here, we're able to generate better truncate code using pack on pre-avx512 targets.
Similar is already done during type legalization. This is the equivalent for op legalization
Differential Revision: https://reviews.llvm.org/D40591
llvm-svn: 319368
|
| |
|
|
|
|
|
| |
To fully avoid trapping on wasm, fptoui needs a second check to ensure that
the operand isn't below the supported range.
llvm-svn: 319354
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40589
llvm-svn: 319353
|
| |
|
|
| |
llvm-svn: 319352
|
| |
|
|
| |
llvm-svn: 319351
|
| |
|
|
|
|
| |
Accidental commit of incomplete patch
llvm-svn: 319346
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A couple of places in LLD were passing references to
TypeTableCollections around, which makes it hard to change the
implementation at runtime. However, these cases only needed to
iterate over the types in the collection, and TypeCollection
already provides a handy abstract interface for this purpose.
By implementing this interface, we can get rid of the need to
pass TypeTableBuilder references around, which should allow us
to swap the implementation at runtime in subsequent patches.
llvm-svn: 319345
|
| |
|
|
| |
llvm-svn: 319340
|
| |
|
|
| |
llvm-svn: 319338
|
| |
|
|
|
|
| |
scheduler classes
llvm-svn: 319337
|
| |
|
|
|
|
|
|
| |
Partially reverting enabling of post-legalization store merge
(r319036) for just ARM backend as it is causing incorrect code
in some Thumb2 cases.
llvm-svn: 319331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Weverything
Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl
aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall
previously aliased.
This should restore the verbosity of a Windows selfhost build back to
its previous levels.
Differential Revision: https://reviews.llvm.org/D40603
llvm-svn: 319330
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40520
llvm-svn: 319329
|
| |
|
|
| |
llvm-svn: 319328
|
| |
|
|
|
|
|
|
|
| |
These are variants of a test that was originally added in:
https://reviews.llvm.org/rL75531
...but removed with:
https://reviews.llvm.org/rL159230
llvm-svn: 319327
|
| |
|
|
|
|
| |
All default to NoItinerary
llvm-svn: 319326
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Detects whether we have the Python modules (pygments, yaml) required by
opt-viewer and hooks this up to REQUIRES.
This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer
testing).
It's also related to https://github.com/apple/swift/pull/12938 and the idea is
to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake.
Differential Revision: https://reviews.llvm.org/D40202
Fixes since the first commit:
1. Disable syntax highlighting as different versions of pygments generate
different HTML
2. Use llvm-cxxfilt from the build
llvm-svn: 319324
|
| |
|
|
|
|
| |
used by any instructions).
llvm-svn: 319321
|
| |
|
|
| |
llvm-svn: 319316
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Patch [1/4] in a series to add parsing of predicates and properly parse SVE ZIP1/ZIP2 instructions.
Reviewers: rengolin, kristof.beyls, fhahn, mcrosier, evandro, echristo, efriedma
Reviewed By: fhahn
Subscribers: aemerson, javed.absar, llvm-commits, tschuett
Differential Revision: https://reviews.llvm.org/D40360
llvm-svn: 319315
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When lowering a G_BRCOND, we generate a TSTri of the condition against
1, which sets the flags, and then a Bcc which branches based on the
value of the flags.
Unfortunately, we were using the wrong condition code to check whether
we need to branch (EQ instead of NE), which caused all our branches to
do the opposite of what they were intended to do. This patch fixes the
issue by using the correct condition code.
llvm-svn: 319313
|
| |
|
|
|
|
| |
instruction scheduler classes
llvm-svn: 319312
|