| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
The call to processPHI already erased MI from its parent, so MI isn't
even valid here, making the getParent() call a use-after-free in
addition to being redundant.
Found by ASan with the ArrayRecycler changes in llvm.org/pr26808.
llvm-svn: 266008
|
|
|
|
|
|
| |
MergeFunctions was refactored a while ago, and Instruction.cpp's comments went out of sync. The content did as well, will fix later.
llvm-svn: 266007
|
|
|
|
| |
llvm-svn: 266006
|
|
|
|
|
|
|
|
|
| |
This is the clang part of http://reviews.llvm.org/D18846.
SafeStack instrumentation pass adds stack protector canaries if both
attributes are present on a function. StackProtector pass will step
back if the function has a safestack attribute.
llvm-svn: 266005
|
|
|
|
|
|
|
|
| |
Add StackProtector to SafeStack. This adds limited protection against
data corruption in the caller frame. Current implementation treats
all stack protector levels as -fstack-protector-all.
llvm-svn: 266004
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is better for a few reasons:
+ It matches the other tooling for iOS.
+ It matches EABI in more cases (i.e. Thumb-mode, and in practice we don't
use ARM mode).
+ It leads to infinitesimally smaller code (0.2%, yay!).
rdar://25369506
llvm-svn: 266003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AtomicExpandPass can now lower atomic load, atomic store, atomicrmw, and
cmpxchg instructions to __atomic_* library calls, when the target
doesn't support atomics of a given size.
This is the first step towards moving all atomic lowering from clang
into llvm. When all is done, the behavior of __sync_* builtins,
__atomic_* builtins, and C11 atomics will be unified.
Previously LLVM would pass everything through to the ISelLowering
code. There, unsupported atomic instructions would turn into __sync_*
library calls. Because of that behavior, Clang currently avoids emitting
llvm IR atomic instructions when this would happen, and emits __atomic_*
library functions itself, in the frontend.
This change makes LLVM able to emit __atomic_* libcalls, and thus will
eventually allow clang to depend on LLVM to do the right thing.
It is advantageous to do the new lowering to atomic libcalls in
AtomicExpandPass, before ISel time, because it's important that all
atomic operations for a given size either lower to __atomic_*
libcalls (which may use locks), or native instructions which won't. No
mixing and matching.
At the moment, this code is enabled only for SPARC, as a
demonstration. The next commit will expand support to all of the other
targets.
Differential Revision: http://reviews.llvm.org/D18200
llvm-svn: 266002
|
|
|
|
|
|
| |
rdar://problem/24401051
llvm-svn: 266001
|
|
|
|
| |
llvm-svn: 266000
|
|
|
|
| |
llvm-svn: 265999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
anytime before LegalizeVectorOprs
xor/and/or (bitcast(A), bitcast(B)) -> bitcast(op (A,B)) was only being combined at the AfterLegalizeTypes stage, this patch permits the combine to occur anytime before then as well.
The main aim with this to improve the ability to recognise bitmasks that can be converted to shuffles.
I had to modify a number of AVX512 mask tests as the basic bitcast to/from scalar pattern was being stripped out, preventing testing of the mmask bitops. By replacing the bitcasts with loads we can get almost the same result.
Differential Revision: http://reviews.llvm.org/D18944
llvm-svn: 265998
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18716
llvm-svn: 265997
|
|
|
|
| |
llvm-svn: 265996
|
|
|
|
| |
llvm-svn: 265995
|
|
|
|
| |
llvm-svn: 265994
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were incorrectly reporting all non-64 bit integers as int64s.
This is most evident when trying to print the "short" type, but
in theory could happen with chars too (although usually chars use
a different builtin type).
Additionally, we were using the wrong check when deciding whether
to print an enum definition as a global enum. We were checking
whether or not the enum was "nested", and if so saving it until
we print the class definition that it was nested in. But this is
not correct in rare situations where the enum is nested, but the
class that it's nested in does not have type information in the PDB.
So instead we check if there is a class definition for the parent
in the PDB. If so we save it for later, otherwise we print it.
llvm-svn: 265993
|
|
|
|
|
|
|
|
| |
This reverts commit r263720.
Just confirmed that s_waitcnt is required after ds_permute/ds_bpermute.
llvm-svn: 265992
|
|
|
|
|
|
|
| |
Add a triple to the run lines so that integers will the same sizes across runs.
Also add a compile time check to ensure the assumptions about sizes are met.
llvm-svn: 265991
|
|
|
|
| |
llvm-svn: 265990
|
|
|
|
| |
llvm-svn: 265989
|
|
|
|
| |
llvm-svn: 265988
|
|
|
|
| |
llvm-svn: 265987
|
|
|
|
|
|
| |
Give them values instead of computing it during relocation.
llvm-svn: 265986
|
|
|
|
| |
llvm-svn: 265985
|
|
|
|
|
|
|
|
| |
Before, ELF at least managed a diagnostic but it was a completely untraceable
"undefined symbol" error. MachO had a variety of even worse behaviours: crash,
emit corrupt file, or an equally bad message.
llvm-svn: 265984
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch ensures that when we detect first-order recurrences, we reject a phi
node if its previous value is also a phi node. During vectorization the initial
and previous values of the recurrence are shuffled together to create the value
for the current iteration. However, phi nodes are not widened like other
instructions. This fixes PR27246.
Differential Revision: http://reviews.llvm.org/D18971
llvm-svn: 265983
|
|
|
|
|
|
|
| |
Updated the expected diagnostics of 17 OpenMP tests.
The changes to each test are identical.
llvm-svn: 265982
|
|
|
|
|
|
| |
They can be regular DefinedSynthetic.
llvm-svn: 265981
|
|
|
|
| |
llvm-svn: 265980
|
|
|
|
| |
llvm-svn: 265979
|
|
|
|
| |
llvm-svn: 265978
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: tejohnson
Subscribers: joker.eph, cfe-commits
Differential Revision: http://reviews.llvm.org/D18947
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265977
|
|
|
|
| |
llvm-svn: 265976
|
|
|
|
|
|
| |
ELF and COFF will now treat .alt_entry like any other unrecognized directive.
llvm-svn: 265975
|
|
|
|
| |
llvm-svn: 265974
|
|
|
|
| |
llvm-svn: 265973
|
|
|
|
|
|
|
|
| |
boilerplate
No functionality change.
llvm-svn: 265972
|
|
|
|
|
|
|
|
|
| |
MachineFrameInfo does not need to be able to distinguish between the
user asking us not to realign the stack and the target telling us it
doesn't support stack realignment. Either way, fixed stack objects have
their alignment clamped.
llvm-svn: 265971
|
|
|
|
| |
llvm-svn: 265970
|
|
|
|
| |
llvm-svn: 265969
|
|
|
|
| |
llvm-svn: 265968
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18907
llvm-svn: 265967
|
|
|
|
| |
llvm-svn: 265966
|
|
|
|
|
|
|
|
|
| |
We need just a couple of logic tweaks to consolidate the shl and lshr cases.
This is step 5 of refactoring to solve PR26760:
https://llvm.org/bugs/show_bug.cgi?id=26760
llvm-svn: 265965
|
|
|
|
|
|
|
|
| |
psll{d|q}512,psllv{16si|8di},psra{d|q}512,psrav{16si|8di},pternlog{d|q}{128|256|512} ) builtin to clang
Differential Revision: http://reviews.llvm.org/D18926
llvm-svn: 265964
|
|
|
|
|
|
|
|
|
|
|
|
| |
compiler-rt is optional. We often get email from users with compiler-rt
build errors who don't actually need compiler-rt. Marking it optional
should help them avoid those potential problems.
While I'm here, update a reference to the build directory and remove an
obsolete reference to llvm-gcc. Nobody today is under the impression
that Clang depends on GCC.
llvm-svn: 265963
|
|
|
|
| |
llvm-svn: 265962
|
|
|
|
|
|
| |
!llvm.dbg.cu.
llvm-svn: 265961
|
|
|
|
|
|
|
|
|
|
| |
This is the straightforward fix for PR26760:
https://llvm.org/bugs/show_bug.cgi?id=26760
But we still need to make some changes to generalize this helper function
and then send the lshr case into here.
llvm-svn: 265960
|
|
|
|
| |
llvm-svn: 265959
|