| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Return bool instead of void so that it is natural to put the calls into
asserts.
llvm-svn: 267033
|
|
|
|
|
|
| |
I get this wrong every time I try to debug this.
llvm-svn: 267030
|
|
|
|
|
|
|
|
| |
When custom lowered, this is not called if the store is custom
lowered. Move it to be a utility function so targets can
easily expand unaligned accesses when custom lowering.
llvm-svn: 267029
|
|
|
|
|
|
|
|
|
| |
Instead of holding a mask, hold two value: the start index and the
length of the mapping. This is a more compact representation, although
less powerful. That being said, arbitrary masks would not have worked
for the generic so do not allow them in the first place.
llvm-svn: 267025
|
|
|
|
|
|
|
| |
If the extracted bits are restricted to the upper half or lower half,
this can be truncated.
llvm-svn: 267024
|
|
|
|
| |
llvm-svn: 267023
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations.
The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used.
The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way.
Differential Revision: http://reviews.llvm.org/D19172
llvm-svn: 267022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
IntrReadWriteArgMem simply becomes IntrArgMemOnly.
So there are fewer intrinsic properties that express their orthogonality
better, and correspond more closely to the corresponding IR attributes.
Suggested by: Philip Reames
Reviewers: joker.eph, reames, tstellarAMD
Subscribers: jholewinski, arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D19291
llvm-svn: 267021
|
|
|
|
| |
llvm-svn: 267019
|
|
|
|
|
|
|
|
| |
r266809 incorrectly used LD to load the stack guard, it should be LWZ.
Differential Revision: http://reviews.llvm.org/D19358
llvm-svn: 267017
|
|
|
|
| |
llvm-svn: 267016
|
|
|
|
|
|
|
| |
These ensure that operand array has at least one element and it is the
self-reference.
llvm-svn: 267015
|
|
|
|
|
|
|
| |
The decl is in LoopUtils.h. I think that this was added to
LoopVersioningLICM.cpp by mistake.
llvm-svn: 267014
|
|
|
|
|
|
|
|
| |
"Into" was misleading. I am also planning to use this helper to look
for loop metadata and return the argument, so find seems like a better
name.
llvm-svn: 267013
|
|
|
|
|
|
| |
This builds on 266999 which made FindAvailableValue do the right thing. Tests included show the newly enabled transforms and those which disabled either due to conservatism or correctness requirements.
llvm-svn: 267006
|
|
|
|
|
|
|
|
| |
Before this fix, DILexicalBlockFile entries were skipped only in some cases and were not in other cases.
Differential Revision: http://reviews.llvm.org/D18724
llvm-svn: 267004
|
|
|
|
|
|
|
|
| |
[NFCI]
This change adds a couple of test cases to make sure FindAvailableLoadedValue does the right thing. At the moment, the code added is dead, but separating it makes follow on changes far more obvious.
llvm-svn: 266999
|
|
|
|
| |
llvm-svn: 266998
|
|
|
|
|
|
| |
We were assuming that only linkonce_odr GVs were lazy linked.
llvm-svn: 266995
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15009
llvm-svn: 266990
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14915
llvm-svn: 266988
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19330
llvm-svn: 266987
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14822
llvm-svn: 266985
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: nhaustov, tstellarAMD
Subscribers: arsenm
Differential Revision: http://reviews.llvm.org/D19317
llvm-svn: 266984
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18855
llvm-svn: 266980
|
|
|
|
|
|
|
|
| |
instructions and add tests for LWM32 and SWM32
Differential Revision: http://reviews.llvm.org/D19150
llvm-svn: 266977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AArch64InstrInfo::optimizeCompareInstr
AArch64InstrInfo::optimizeCompareInstr has bug PR27158 which causes generation of incorrect code.
A compare instruction is substituted with another instruction which does not
produce the same flags as the original compare instruction.
This patch contains:
1. Fix of the bug.
2. A regression test in MIR.
3. A new test to check that SUBS is replaced by SUB.
Differential Revision: http://reviews.llvm.org/D18838
llvm-svn: 266969
|
|
|
|
| |
llvm-svn: 266968
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266965
|
|
|
|
| |
llvm-svn: 266963
|
|
|
|
|
|
| |
EXTRACT_VECTOR_ELT/INSERT_VECTOR_ELT from SSE41 block. They were already done in an earlier block. NFC
llvm-svn: 266962
|
|
|
|
|
|
| |
Instead let them stay Legal and mark them Expand for specific types where needed. Reduces overall number of calls to setOperationAction. NFC
llvm-svn: 266961
|
|
|
|
|
|
| |
operations to Expand. These vector types aren't legal so these operations would never make it far enough to need to expand. NFC
llvm-svn: 266960
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18494
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266959
|
|
|
|
|
|
|
|
|
|
|
|
| |
This help to streamline the process of handling importing since
we don't need to special case alias everywhere: just like
linkonce_odr function, make sure at least one alias is emitted
by turning it weak.
Differential Revision: http://reviews.llvm.org/D19308
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
`llvm.guard(false)` always bails out of the current compilation unit, so
we can prune any control flow following it.
Reviewers: hfinkel, pcc, reames
Subscribers: majnemer, reames, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D19245
llvm-svn: 266955
|
|
|
|
|
|
|
|
| |
types where we can't do any better than the Custom lowering of CTTZ. LegalizeVectorOps will expand to CTTZ since its marked Custom.
CTTZ_ZERO_UNDEF can be custom lowered specially if CTLZ is supported. Otherwise CTTZ and CTTZ_ZERO_UNDEF are handled the same way by using CTPOP and bitmath.
llvm-svn: 266952
|
|
|
|
|
|
|
|
| |
CTTZ_ZERO_UNDEF/CTLZ_ZERO_UNDEF to CTTZ/CTLZ directly if those ops are Legal/Custom instead of deferring it to LegalizeOps.
This is needed to support CTTZ/CTLZ Custom correctly since LegalizeOps would be too late to do the custom lowering.
llvm-svn: 266951
|
|
|
|
|
|
|
|
| |
instructions.
Without BWI we have to split the vectors into 256-bit vectors so we can use AVX2 pshufb and then concatenate the results.
llvm-svn: 266950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The iteratitive algorithm from r265456 claimed but failed to create a
post-order traversal. It had the same error that was fixed in the
ValueEnumerator in r266947: now, instead of pushing all operands on the
worklist at once, we pause whenever an operand gets pushed in order to
go depth-first (I know, it sounds obvious).
Sadly, I have no idea how to observe this from outside the algorithm and
so I haven't written a test. The output should be the same; it should
just use fewer temporary nodes now. I've added some comments that I
hope make the current logic clear enough it's unlikely to regress.
llvm-svn: 266949
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
performing importing
Summary:
The function importer already decided what symbols need to be pulled
in. Also these magically added ones will not be in the export list
for the source module, which can confuse the internalizer for
instance.
Reviewers: tejohnson, rafael
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D19096
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266948
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Emit metadata nodes in post-order. The iterative algorithm from r266709
failed to maintain this property. After understanding my mistake, it
wasn't too hard to write a test with llvm-bcanalyzer (and I've actually
made this change once before: see r220340).
This also reverts the "noisy" testcase change from r266709. That should
have been more of a red flag :/.
Note: The same bug crept into the ValueMapper in r265456. I'm still
working on the fix.
llvm-svn: 266947
|
|
|
|
| |
llvm-svn: 266946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on knowledge of the sign bit for A and B.
No matter what value you OR in to A, the result of (or A, B) is going to be UGE A. When A and B are positive, it's SGE too. If A is negative, OR'ing a value into it can't make it positive, but can increase its value closer to -1, therefore (or A, B) is SGE A. Working through all possible combinations produces this truth table:
```
A is
+, -, +/-
F F F + B is
T F ? -
? F ? +/-
```
The related optimizations are flipping the 'slt' for 'sge' which always NOTs the result (if the result is known), and swapping the LHS and RHS while swapping the comparison predicate.
There are more idioms left to implement (aren't there always!) but I've stopped here because any more would risk becoming unreasonable for reviewers.
llvm-svn: 266939
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch refined the instruction weight anootation algorithm:
1. Do not use dbg_value intrinsics for annotation.
2. Annotate cold calls if the call is inlined in profile, but not inlined before preparation. This indicates that the annotation preparation step found no sample for the inlined callsite, thus the call should be very cold.
Reviewers: dnovillo, davidxl
Subscribers: mgrang, llvm-commits
Differential Revision: http://reviews.llvm.org/D19286
llvm-svn: 266936
|
|
|
|
|
|
|
| |
is another place that libObject’s getName() for symbols returns Expected<...>
that needed to be updated.
llvm-svn: 266933
|
|
|
|
|
|
|
| |
lib/Object/MachOObjectFile.cpp:53:44: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move]
return malformedError(Obj.getFileName(), std::move(Msg.str()), ECOverride);
llvm-svn: 266930
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm-objdump to produce a good error message.
Produce another specific error message for a malformed Mach-O file when a symbol’s
string index is past the end of the string table. The existing test case in test/Object/macho-invalid.test
for macho-invalid-symbol-name-past-eof now reports the error with the message indicating
that a symbol at a specific index has a bad sting index and that bad string index value.
Again converting interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. Where the existing code reported the error with a
string message or an error code it was converted to do the same. There is some
code for this that could be factored into a routine but I would like to leave that for
the code owners post-commit to do as they want for handling an llvm::Error. An
example of how this could be done is shown in the diff in
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine
already for std::error_code so I added one like it for llvm::Error .
Also there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values. So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comment:
“// TODO: Actually report errors helpfully” and a call something like
consumeError(NameOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.
Note there fixes needed to lld that goes along with this that I will commit right after this.
So expect lld not to built after this commit and before the next one.
llvm-svn: 266919
|
|
|
|
|
|
|
| |
This is for compatibility with scripts that use -mv5, etc. with the
assembler.
llvm-svn: 266918
|
|
|
|
|
|
|
|
|
|
| |
Don't use std::vector<TrackingMDRef>, since (at least in some versions
of libc++) std::vector apparently copies values on grow operations
instead of moving them. Found this when I was temporarily deleting the
copy constructor for TrackingMDRef to investigate a performance
bottleneck.
llvm-svn: 266909
|