| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See PR25822 for a more full summary, but we were conflating the concepts of "capture" and "escape". We were proving nocapture and using that proof to infer noescape, which is not true. Escaped-ness is a function-local property - as soon as a value is used in a call argument it escapes. Capturedness is a related but distinct property. It implies a *temporally limited* escape. Consider:
static int a;
int b;
int g(int * nocapture arg);
int f() {
a = 2; // Even though a escapes to g, it is not captured so can be treated as non-escaping here.
g(&a); // But here it must be treated as escaping.
g(&b); // Now that g(&a) has returned we know it was not captured so we can treat it as non-escaping again.
}
The original commit did not sufficiently understand this nuance and so caused PR25822 and PR26046.
r248576 included both a performance improvement (which has been backed out) and a related conformance fix (which has been kept along with its testcase).
llvm-svn: 257058
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15925
llvm-svn: 257056
|
| |
|
|
|
|
|
|
| |
AVX1 v8i32/v4i64 shuffles are bitcasted to v8f32/v4f64, this patch peeks through bitcasts to check for a load node to allow broadcasts to occur.
Follow up to D15310
llvm-svn: 257055
|
| |
|
|
| |
llvm-svn: 257049
|
| |
|
|
|
|
|
|
|
|
| |
Change Triple::get32BitArchVariant to return arm/armeb as the 32bit
variant of aarch64/aarch64_be and do the same change for the oppoiste
direction in Triple::get64BitArchVariant.
Differential revision: http://reviews.llvm.org/D15529
llvm-svn: 257048
|
| |
|
|
| |
llvm-svn: 257047
|
| |
|
|
|
|
| |
Follow up to D15378, added INSERTPS to the list of decodable target shuffles and enabled XFormVExtractWithShuffleIntoLoad to handle target shuffles with SentinelZero and tested this with INSERTPS.
llvm-svn: 257046
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15934
llvm-svn: 257044
|
| |
|
|
|
|
|
|
| |
Darwin TLS accesses most closely resemble ELF's general-dynamic situation,
since they have to be able to handle all possible situations. The descriptors
and so on are obviously slightly different though.
llvm-svn: 257039
|
| |
|
|
| |
llvm-svn: 257037
|
| |
|
|
|
|
|
|
|
|
| |
Serialize will perform a hardware serialization operation, and is
acting as a memory barrier. Therefore it must have the hasSideEffects
flag set so it will be treated as a global memory object.
Reviewed by Ulrich Weigand
llvm-svn: 257036
|
| |
|
|
| |
llvm-svn: 257035
|
| |
|
|
| |
llvm-svn: 257034
|
| |
|
|
| |
llvm-svn: 257033
|
| |
|
|
|
|
| |
there remove a superfluous _Q from the instruction names.
llvm-svn: 257032
|
| |
|
|
|
|
| |
option.
llvm-svn: 257031
|
| |
|
|
| |
llvm-svn: 257030
|
| |
|
|
| |
llvm-svn: 257028
|
| |
|
|
| |
llvm-svn: 257026
|
| |
|
|
|
|
|
|
|
|
| |
Unlike my comment in 257022 said, it turns out we do handle constant vectors in the statepoint lowering, but only because SelectionDAG doesn't actually produce constants for them. Add a couple of tests which show this working.
Also, add a triple to the same test file to hopefully fix a failing bot.
It turns out we do han
llvm-svn: 257025
|
| |
|
|
|
|
|
|
| |
reduce the critical path
Allow fadd/fmul to be reassociated in aarch64.
llvm-svn: 257024
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, we try to split vectors of pointers back into their component pointer elements during rewrite-statepoints-for-gc. This is less than ideal since presumably the vectorizer chose to vectorize for a reason. :) It's also been a source of bugs - in particular, the relocation logic as currently implemented was recently discovered to be wrong.
The alternate approach is to allow gc.relocates of vector-of-pointer type and update the backend to handle them. That's what this patch tries to do. This won't actually enable vector-of-pointers in practice - there are some RS4GC changes needed - but the lowering is standalone and testable so it makes sense to separate.
Note that there are some known cases around vector constants which this patch does not handle. Once this is in, I'll send another patch with individual fixes and test cases.
Differential Revision: http://reviews.llvm.org/D15632
llvm-svn: 257022
|
| |
|
|
|
|
|
| |
This enables ELF-style name mangling, which primarily means using ".L" for
private symbols.
llvm-svn: 257020
|
| |
|
|
|
|
|
|
|
| |
Follow-up to r257000: DIImportedEntity can reach a DISubprogram via
its entity, but also via its scope. Handle the latter case as well.
PR26037.
llvm-svn: 257019
|
| |
|
|
|
|
| |
At the moment, this is essentially a diangostic option so that I can start collecting failing test cases, but we will eventually migrate to removing the vector splitting code entirely.
llvm-svn: 257015
|
| |
|
|
| |
llvm-svn: 257013
|
| |
|
|
|
|
|
|
|
|
|
| |
We need to know whether or not a given basic block is in a loop for the analysis
to be correct.
Loop information may be incomplete on irreducible CFGs, therefore we may
generate incorrect code if we use it in those situations.
This fixes PR25988.
llvm-svn: 257012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r252532 added support for reporting the monolithic library
when LLVM_BUILD_LLVM_DYLIB is used. This would only be done
if the individual components were not found, and the dynamic
library is found.
This diff extends this as follows:
- If LLVM_LINK_LLVM_DYLIB is set, then prefer the shared
library, even if all component libraries exist.
- Two flags, --link-shared and --link-static are introduced
to provide explicit guidance. If --link-shared is passed
and the shared library does not exist, an error results.
Additionally, changed the expected shared library names from
(e.g.) LLVM-3.8.0 to LLVM-3.8. The former exists only in an
installation (and then only in CMake builds I think?), and not
in the build tree; this breaks usage of llvm-config during
builds, e.g. by llvm-go.
Reviewers: DiamondLovesYou, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15033
llvm-svn: 257003
|
| |
|
|
|
|
|
|
|
|
| |
It is illegal to have a null entity in a DIImportedEntity, so
we must link in a DISubprogram metadata node referenced by one,
even if the associated function is not linked in or inlined anywhere.
Fixes PR26037.
llvm-svn: 257000
|
| |
|
|
|
|
|
|
|
|
| |
the store destination position
This is a conservative fix, I expect Amaury to relax this.
Follow-up for r256923
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 256999
|
| |
|
|
| |
llvm-svn: 256998
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
getTargetShuffleMask may return shuffle masks with SM_SentinelZero (-2) values (currently just for PSHUFB but VPERM2X128 as well with this patch). Although some calling functions can make use of this (mainly for shuffle combining), others can not and their inclusion makes shuffle mask comparisons more difficult.
This patch adds a flag to getTargetShuffleMask to indicate if the calling function can't handle SM_SentinelZero; getTargetShuffleMask will then return false if it occurs to make handling much easier.
I've tidied up some uses of getTargetShuffleMask to better indicate what is going on - more could be done but at present I don't have test cases to demonstrate it.
Some upcoming patches will make use of this to both support more uses where SM_SentinelZero is not permitted (e.g. combineShuffleToAddSub), and also will allow us to add INSERTPS support to getTargetShuffleMask as part of better zero handling discussed in D14261.
Differential Revision: http://reviews.llvm.org/D15378
llvm-svn: 256992
|
| |
|
|
|
|
|
|
| |
With r256990, bogner introduced comprehensive tests for constant arrays
and vectors. We no longer need the existing ones because they are
redundant.
llvm-svn: 256991
|
| |
|
|
|
|
|
|
| |
I added a couple of tests in r256982, but vedantk suggested that they
fit better into compatibility.ll, since they could catch format breaks
later on there.
llvm-svn: 256990
|
| |
|
|
|
|
|
|
| |
Fix lit test fail due to outputting an extra line.
Differential Revision: http://reviews.llvm.org/D15776
llvm-svn: 256987
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In r254991 I allowed ConstantDataVectors to contain elements of
HalfTy, but I missed updating the bitcode reader and writer to handle
this, so now we crash if we try to emit bitcode on programs that have
constant vectors of half.
This fixes the issue and adds test coverage for reading and writing
constant sequences in bitcode.
llvm-svn: 256982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is admittedly something that you could only run into by manually
playing around with shader assembly because the SITypeWriter pass is
skipped for compute.
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15902
llvm-svn: 256980
|
| |
|
|
| |
llvm-svn: 256973
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
only if it has some uses
Summary: This patch adds a check in SplitLandingPadPredecessors to see if the original landingpad instruction has any uses. If not, we don't need to create a PHINode for it in the joint block since it's gonna be a dead code anyway. The motivation for this patch is that we found a bug that SplitLandingPadPredecessors created a PHINode of token type landingpad, which failed the verifier since PHINode can not be token type. However, the created PHINode will never be used in our code pattern. This patch will workaround this bug, and we might add supports in SplitLandingPadPredecessors to handle token type landingpad with uses in the future.
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15835
llvm-svn: 256972
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. This will allow the optimizer to pick up on it.
Reviewers: craig.topper, spatel, dexonsmith, Prazek, chandlerc, joker.eph, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15923
llvm-svn: 256969
|
| |
|
|
| |
llvm-svn: 256968
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move the logic from BranchFolding to use the shared infrastructure for merging MMOs introduced in 256909. This has the effect of making BranchFolding more capable.
In the process, fix a latent bug. The existing handling for merging didn't handle the case where one of the instructions being merged had overflowed and dropped MemRefs. This was a latent bug in the places the code was commoned from, but potentially reachable in BranchFolding.
Once this is in, we're left with a single place to consider implementing MMO unique-ing as proposed in http://reviews.llvm.org/D15230.
Differential Revision: http://reviews.llvm.org/D15913
llvm-svn: 256966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functionality that calculateCatchReturnSuccessorColors provides was
once non-trivial: it was a computation layered on top of funclet
coloring.
These days, LLVM IR directly encodes what
calculateCatchReturnSuccessorColors computed, obsoleting the need for
it.
No functionality change is intended.
llvm-svn: 256965
|
| |
|
|
| |
llvm-svn: 256964
|
| |
|
|
|
|
|
|
|
| |
TLS calls need the stack frame to be properly set up and this
implies that such calls need ADJUSTSTACK_xxx markers.
Fixes PR25820.
llvm-svn: 256959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's
binaries. Turning it off is useful for deterministic builds.
r246905 made it so that the define suddenly also controls if the binaries that
the llvm binaries _create_ embed timestamps or not – but this shouldn't be a
configure-time option. r256203/r256204 added a driver option to toggle this on
and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS
builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is
deterministic – but the built clang can still write timestamps into other
executables when requested.
This also allows removing some of the test machinery added in r292012 to work
around this problem.
See PR24740 for background.
http://reviews.llvm.org/D15783
llvm-svn: 256958
|
| |
|
|
|
|
|
| |
The code duplication contributed to PR25754:
https://llvm.org/bugs/show_bug.cgi?id=25754
llvm-svn: 256957
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
FindIDom() can fail in two different ways - it can either return nullptr or the
block itself, depending on the circumstances. Some users of FindIDom() check
one error condition, while others check the other.
Change it to always return nullptr on failure.
This fixes PR26004.
Differential Revision: http://reviews.llvm.org/D15847
llvm-svn: 256955
|
| |
|
|
| |
llvm-svn: 256954
|
| |
|
|
|
|
|
|
| |
The first instruction in a block is what the rend() iterator points to, so
if it moves, we need to re-evaluate rend() so that we continue to iterate
through the rest of the instructions.
llvm-svn: 256953
|