| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
This reverts commit 2b52880592a525cfe04d8f9008a35da8c2ea94c3.
Needs review.
llvm-svn: 185806
|
|
|
|
|
|
|
| |
I was originally going to use MVC for memmove too, but that's less of
a clear win. Remove some accidental left-overs in the previous commit.
llvm-svn: 185804
|
|
|
|
|
|
|
| |
Use MVC for memcpy in cases where a single MVC is enough. Using MVC is
a win for longer copies too, but I'll leave that for later.
llvm-svn: 185802
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug (found by llvm-stress) in
DAGTypeLegalizer::PromoteIntRes_BUILD_VECTOR where it assumed that the result
type would always be larger than the original operands. This is not always
true, however, with boolean vectors. For example, promoting a node of type v8i1
(where the operands will be of type i32, the type to which i1 is promoted) will
yield a node with a result vector element type of i16 (and operands of type
i32). As a result, we cannot blindly assume that we can ANY_EXTEND the operands
to the result type.
llvm-svn: 185794
|
|
|
|
| |
llvm-svn: 185793
|
|
|
|
| |
llvm-svn: 185791
|
|
|
|
| |
llvm-svn: 185790
|
|
|
|
| |
llvm-svn: 185788
|
|
|
|
|
|
|
|
| |
This fixes an oversight that Intrinsic::nearbyint was not being mapped to
ISD::FNEARBYINT (thus fixing the over-optimistic cost we were assigning to
nearbyint calls for some targets).
llvm-svn: 185783
|
|
|
|
|
|
| |
This reverts commit 01f8d579f7672872324208ac5bc4ac311e81b22e.
llvm-svn: 185781
|
|
|
|
| |
llvm-svn: 185780
|
|
|
|
| |
llvm-svn: 185778
|
|
|
|
| |
llvm-svn: 185777
|
|
|
|
|
|
| |
pointer arguments.
llvm-svn: 185776
|
|
|
|
|
|
|
|
|
| |
This is a complete re-write if the bottom-up vectorization class.
Before this commit we scanned the instruction tree 3 times. First in search of merge points for the trees. Second, for estimating the cost. And finally for vectorization.
There was a lot of code duplication and adding the DCE exposed bugs. The new design is simpler and DCE was a part of the design.
In this implementation we build the tree once. After that we estimate the cost by scanning the different entries in the constructed tree (in any order). The vectorization phase also works on the built tree.
llvm-svn: 185774
|
|
|
|
|
|
|
| |
Upon further reflection, the alias analysis part of r185764 is not a safe
change.
llvm-svn: 185770
|
|
|
|
|
|
| |
not modify the ref count of an objc object and additionally are inert for modref purposes.
llvm-svn: 185769
|
|
|
|
|
|
| |
brace)
llvm-svn: 185768
|
|
|
|
| |
llvm-svn: 185767
|
|
|
|
|
|
| |
references to entrypoint declarations as well.
llvm-svn: 185764
|
|
|
|
| |
llvm-svn: 185763
|
|
|
|
|
|
|
|
|
|
|
| |
Obviously the personality function should be emitted as language handler
instead of the hard coded _GCC_specific_handler. The language specific
data must be placed after the unwind information therefore it must not
be emitted into a separate section.
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185761
|
|
|
|
|
|
|
|
|
|
|
| |
For alignment purposes, the instruction array will always have an even
number of entries, with the final entry potentially unused (in which
case the array will be one longer than indicated by the count of unwind
codes field).
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
data structures.
The Win64 EH data structures must be of type IMAGE_REL_AMD64_ADDR32NB
instead of IMAGE_REL_AMD64_ADDR32. This is easiely achieved by adding
the VK_COFF_IMGREL32 modifier to the symbol reference.
Change also references to start and end of the SEH range of a function
as offsets to start of the function.
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185759
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code offset for unwind code SET_FPREG is wrong because it is set
to constant 0. The fix is to do the same as for the other unwind
codes: emit a label and later the absolute difference between the
label and the begin of the prologue.
Also enables the failing test case MC/COFF/seh.s
Reviewed by Charles Davis and Nico Rieck.
llvm-svn: 185758
|
|
|
|
| |
llvm-svn: 185757
|
|
|
|
|
|
|
|
|
|
|
|
| |
ReduceLoadWidth unconditionally drops extensions from loads. Limit it to the
case when all of the bits the extension would otherwise produce are dropped by
the shrink. It would be possible to shrink the load in more cases by merging
the extensions, but this isn't trivial and a very rare case. I left a TODO for
that case.
Fixes PR16551.
llvm-svn: 185755
|
|
|
|
|
|
|
|
| |
This prevents the emission of DAG-generated vreg definitions after a
tail call be dropping them entirely (on the grounds that nothing could
use them anyway, and they interfere with O0 CodeGen).
llvm-svn: 185754
|
|
|
|
| |
llvm-svn: 185753
|
|
|
|
| |
llvm-svn: 185748
|
|
|
|
|
|
| |
an llvm_unreachable after the switch to quiet -Wreturn_type errors.
llvm-svn: 185746
|
|
|
|
|
|
|
|
| |
some small cleanups.
This fixes an issue that came up due to -fpermissive on the bots.
llvm-svn: 185744
|
|
|
|
| |
llvm-svn: 185743
|
|
|
|
| |
llvm-svn: 185742
|
|
|
|
| |
llvm-svn: 185741
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first patch in a series of 3 patches which clean up how we create
runtime function declarations in the ARC optimizer when they do not exist
already in the IR.
Currently we have a bunch of duplicated code in ObjCARCOpts, ObjCARCContract
that does this. This patch refactors that code into a separate class called
ARCRuntimeEntryPoints which lazily creates the declarations for said
entrypoints.
The next two patches will consist of the work of refactoring
ObjCARCContract/ObjCARCOpts to use this new code.
llvm-svn: 185740
|
|
|
|
| |
llvm-svn: 185738
|
|
|
|
|
|
|
| |
functions. Make the function attributes pass add it to known library functions
and when it can deduce it.
llvm-svn: 185735
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 185733
|
|
|
|
| |
llvm-svn: 185731
|
|
|
|
| |
llvm-svn: 185728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function is complementary to createTemporaryFile. It handles the case were
the unique file is *not* temporary: we will rename it in the end. Since we
will rename it, the file has to be in the same filesystem as the final
destination and we don't prepend the system temporary directory.
This has a small semantic difference from unique_file: the default mode is 0666.
This matches the behavior of most unix tools. For example, with this change
lld now produces files with the same permissions as ld. I will add a test
of this change when I port clang over to createUniqueFile (next commit).
llvm-svn: 185726
|
|
|
|
| |
llvm-svn: 185719
|
|
|
|
|
|
|
|
| |
This function is inspired by clang's Driver::GetTemporaryPath. It hides the
pattern used for uniquing and requires simple file names that are always
placed in the system temporary directory.
llvm-svn: 185716
|
|
|
|
| |
llvm-svn: 185714
|
|
|
|
|
|
|
|
|
|
|
| |
A "pkhtb x, x, y asr #num" uses the lower 16 bits of "y asr #num" and packs them
in the bottom half of "x". An arithmetic and logic shift are only equivalent in
this context if the shift amount is 16. We would be shifting in ones into the
bottom 16bits instead of zeros if "y" is negative.
radar://14338767
llvm-svn: 185712
|
|
|
|
| |
llvm-svn: 185709
|
|
|
|
|
|
|
|
|
|
|
| |
The stack coloring pass has code to delete stores and loads that become
trivially dead after coloring. Extend it to cope with single instructions
that copy from one frame index to another.
The testcase happens to show an example of this kicking in at the moment.
It did occur in Real Code too though.
llvm-svn: 185705
|
|
|
|
|
|
|
|
|
|
| |
This fixes foldMemoryOperandImpl() so that it doesn't create duplicated
frame MMOs. I hadn't realized when writing r185434 that it was the caller's
responsibility to add these.
No behavioural change intended.
llvm-svn: 185704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stack coloring pass renumbered frame indexes with a loop of the form:
for each frame index FI
for each instruction I that uses FI
for each use of FI in I
rename FI to FI'
This caused problems if an instruction used two frame indexes F0 and F1
and if F0 was renamed to F1 and F1 to F2. The first time we visited the
instruction we changed F0 to F1, then we changed both F1s to F2.
In other words, the problem was that SSRefs recorded which instructions
used an FI, but not which MachineOperands and MachineMemOperands within
that instruction used it.
This is easily fixed for MachineOperands by walking the instructions
once and processing each operand in turn. There's already a loop to
do that for dead store elimination, so it seemed more efficient to
fuse the two at the block level.
MachineMemOperands are more tricky because they can be shared between
instructions. The patch handles them by making SSRefs an array of
MachineMemOperands rather than an array of MachineInstrs. We might end
up processing the same MachineMemOperand twice, but that's OK because
we always know from the SSRefs index what the original frame index was.
llvm-svn: 185703
|