| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
No real functionality change here, just avoiding an unnecessary copy of
std::vector<TrackingMDRef> for every subprogram with variables.
llvm-svn: 266907
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is done for consistency with asan-use-after-return.
I see no other users than tests.
Reviewers: aizatsky, kcc
Differential Revision: http://reviews.llvm.org/D19306
llvm-svn: 266906
|
| |
|
|
| |
llvm-svn: 266905
|
| |
|
|
|
|
| |
Phabricator Revision: http://reviews.llvm.org/D19277
llvm-svn: 266904
|
| |
|
|
| |
llvm-svn: 266903
|
| |
|
|
|
|
|
|
| |
A ModuleSlotTracker can be created without actually being used (e.g.,
r266889 added one to the Verifier). Create the SlotTracker within it
lazily on the first call to ModuleSlotTracker::getMachine.
llvm-svn: 266902
|
| |
|
|
| |
llvm-svn: 266901
|
| |
|
|
|
|
| |
I missed this site in r266889.
llvm-svn: 266900
|
| |
|
|
|
|
|
|
| |
Differentiate between word and subword memory operations as they take different
amount of cycles to complete. This just adds a basic model of the subword
latency to the scheduler.
llvm-svn: 266898
|
| |
|
|
| |
llvm-svn: 266897
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19334
llvm-svn: 266895
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clients may call writeMergedModules before calling optimize, or call
compileOptimized without calling optimize. Make sure they don't sneak
past the verifier. This adds LTOCodeGenerator::verifyMergedModuleOnce,
and calls it from writeMergedModule, optimize, and codegenOptimized.
I couldn't find a good way to test this. I tried writing broken IR to
send into llvm-lto, but LTOCodeGenerator doesn't understand textual IR,
and assembler runs the verifier itself anyway. Checking in
valid-but-doesn't-verify bitcode here doesn't seem valuable.
llvm-svn: 266894
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function or not.
The alias handling was specific to the old iterative inlining
mechanism, so that is dead now. The variable handling could make a
difference, since we were previously falling through to the normal
selection logic, but we don't observe changes in the validation
because no client seems to rely on it.
Differential Revision: http://reviews.llvm.org/D19307
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266893
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Speed up Verifier output by sharing a single ModuleSlotTracker for the
duration. There should be no functionality change here except for much
faster output when there's more than one statement.
Now the Verifier won't be traversing the full Metadata graph every time
it prints an error. The TypePrinter is still not shared, but that would
take some extra plumbing.
llvm-svn: 266889
|
| |
|
|
|
|
|
|
| |
While using a raw_null_ostream meant that the Verifier didn't have to
think about whether to print, it's actually quite expensive to print out
IR. Only print if the output is going somewhere.
llvm-svn: 266884
|