This allows the function to be easily reused and also simplifies the
code as the keyword list is next to the keyword handling now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251478 91177308-0d34-0410-b5e6-96231b3b80d8
r248010 changed the -debug output to use short ids, but did not
similarly modify the graph printer. Change to be consistent, for ease of
cross-reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251465 91177308-0d34-0410-b5e6-96231b3b80d8
CatchReturnInst has side-effects: it runs a destructor. This destructor
could conceivably run forever/call exit/etc. and should not be removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251461 91177308-0d34-0410-b5e6-96231b3b80d8
We used automated tools to update our IR to its current syntax in commit
21f77df7(r247378). While it correctly updated the CHECK lines in our
compatibility tests, the IR should have remained untouched. This commit
fixes the syntax errors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251458 91177308-0d34-0410-b5e6-96231b3b80d8
Use 10 bits to represent calling convention ID's instead of 13, and
update the bitcode compatibility tests accordingly. We now error-out in
the bitcode reader when we see bad calling conv ID's.
Thanks to rnk and dexonsmith for feedback!
Differential Revision: http://reviews.llvm.org/D13826
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251452 91177308-0d34-0410-b5e6-96231b3b80d8
AliasSetTracker does not need to convert the access mode to ModRefAccess if the
new visited UnknownInst has only 'REF' modrefinfo to existing pointers in the
sets.
Patch by Andrew Zhogin!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251451 91177308-0d34-0410-b5e6-96231b3b80d8
This is a usage of the IR-level fast-math-flags now that they are propagated to SDNodes.
This was originally part of D8900.
Removing the global 'enable-unsafe-fp-math' checks will require auto-upgrade and
possibly other changes.
Differential Revision: http://reviews.llvm.org/D9708
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251450 91177308-0d34-0410-b5e6-96231b3b80d8
A PHI on a catchpad might be used by both edges out of the catchpad,
feeding back into a loop. In this case, just use the insertion point.
Anything more clever would require new basic blocks or PHI placement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251442 91177308-0d34-0410-b5e6-96231b3b80d8
This recommits r250719, which caused a failure in SPEC2000.gcc
because of the incorrect insert point for the new wider load.
Convert two halfword loads into a single 32-bit word load with bitfield extract
instructions. For example :
ldrh w0, [x2]
ldrh w1, [x2, #2]
becomes
ldr w0, [x2]
ubfx w1, w0, #16, #16
and w0, w0, #ffff
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251438 91177308-0d34-0410-b5e6-96231b3b80d8
When optimization is disabled, edge weights that are stored in MBB won't be used so that we don't have to store them. Currently, this is done by adding successors with default weight 0, and if all successors have default weights, the weight list will be empty. But that the weight list is empty doesn't mean disabled optimization (as is stated several times in MachineBasicBlock.cpp): it may also mean all successors just have default weights.
We should discourage using default weights when adding successors, because it is very easy for users to forget update the correct edge weights instead of using default ones (one exception is that the MBB only has one successor). In order to detect such usages, it is better to differentiate using default weights from the case when optimizations is disabled.
In this patch, a new interface addSuccessorWithoutWeight(MBB*) is created for when optimization is disabled. In this case, MBB will try to maintain an empty weight list, but it cannot guarantee this as for many uses of addSuccessor() whether optimization is disabled or not is not checked. But it can guarantee that if optimization is enabled, then the weight list always has the same size of the successor list.
Differential revision: http://reviews.llvm.org/D13963
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251429 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change could be way off-piste, I'm looking for any feedback on whether it's an acceptable approach.
It never seems to be a problem to gobble up as many reduction values as can be found, and then to attempt to reduce the resulting tree. Some of the workloads I'm looking at have been aggressively unrolled by hand, and by selecting reduction widths that are not constrained by a vector register size, it becomes possible to profitably vectorize. My test case shows such an unrolling which SLP was not vectorizing (on neither ARM nor X86) before this patch, but with it does vectorize.
I measure no significant compile time impact of this change when combined with D13949 and D14063. There are also no significant performance regressions on ARM/AArch64 in SPEC or LNT.
The more principled approach I thought of was to generate several candidate tree's and use the cost model to pick the cheapest one. That seemed like quite a big design change (the algorithms seem very much one-shot), and would likely be a costly thing for compile time. This seemed to do the job at very little cost, but I'm worried I've misunderstood something!
Reviewers: nadav, jmolloy
Subscribers: mssimpso, llvm-commits, aemerson
Differential Revision: http://reviews.llvm.org/D14116
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251428 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently, when the SLP vectorizer considers whether a phi is part of a reduction, it dismisses phi's whose incoming blocks are not the same as the block containing the phi. For the patterns I'm looking at, extending this rule to allow phis whose incoming block is a containing loop latch allows me to vectorize certain workloads.
There is no significant compile-time impact, and combined with D13949, no performance improvement measured in ARM/AArch64 in any of SPEC2000, SPEC2006 or LNT.
Reviewers: jmolloy, mcrosier, nadav
Subscribers: mssimpso, nadav, aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D14063
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251425 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Certain workloads, in particular sum-of-absdiff loops, can be vectorized using SLP if it can treat select instructions as reduction values.
The test case is a bit awkward. The AArch64 cost model needs some tuning to not be so pessimistic about selects. I've had to tweak the SLP threshold here.
Reviewers: jmolloy, mzolotukhin, spatel, nadav
Subscribers: nadav, mssimpso, aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D13949
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251424 91177308-0d34-0410-b5e6-96231b3b80d8
When emitting a remark for a conditional branch annotation, the remark
uses the line location information of the conditional branch in the
message. In some cases, that information is unavailable and the
optimization would segfaul. I'm still not sure whether this is a bug or
WAI, but the optimizer should not die because of this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251420 91177308-0d34-0410-b5e6-96231b3b80d8
The existing behavior was correct on Darwin, which is probably the
platform it was written for.
Before this change, we would rewrite "align 8" to ".align 3" and then
fail to make it through the integrated assembler because 3 is not a
power of 2.
Differential Revision: http://reviews.llvm.org/D14120
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251418 91177308-0d34-0410-b5e6-96231b3b80d8
For CloudABI's toolchain I have a symlink that goes from <target>-ar and
<target>-ranlib to LLVM's ar binary, to mimick GNU Binutils' naming
scheme. The problem is that if we're targetting ARM64, the name of the
ranlib executable is aarch64-unknown-cloudabi-ranlib. This already
contains the string "ar".
Let's move the "ranlib" test above the "ar" test. It's not that likely
that we're going to see operating systems or harwdare architectures that
are called "ranlib".
Reviewed by: rafael
Differential Revision: http://reviews.llvm.org/D14123
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251413 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We've had a lot of discussion in the past about the meaningful and useful default behaviors for the llvm-shlib tool. The original implementation was heavily geared toward Apple's use, and I think that was wrong. This patch seeks to correct that.
I've removed the LLVM_DYLIB_EXPORT_ALL variable and made libLLVM export everything by default.
I've also added a new target that is only built on Darwin for libLLVM-C as a library that re-exports the LLVM-C API. This library is not built on Linux because ELF doesn't support re-export libraries in the same way MachO does.
Reviewers: chapuni, resistor, bogner, axw
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13842
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251411 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: After D13851 landed, we saw backend crashes when compiling the reduced test case included in this patch. The right fix seems to be to allow these vector types for expansion in instruction selection.
Reviewers: rengolin, t.p.northover
Subscribers: RKSimon, t.p.northover, aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14082
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251401 91177308-0d34-0410-b5e6-96231b3b80d8
We want to insert no-op casts as close as possible to the def. This is
tricky when the cast is of a PHI node and the BasicBlocks between the
def and the use cannot hold any instructions. Iteratively walk EH pads
until we hit a non-EH pad.
This fixes PR25326.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251393 91177308-0d34-0410-b5e6-96231b3b80d8
This avoid mentioning the table name an extra time and allows the lookup to be done directly in the ifs by relying on the bool conversion of the pointer.
While there make use of ArrayRef and std::find_if.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251382 91177308-0d34-0410-b5e6-96231b3b80d8
No functionality changed here, but the indentation is substantially
reduced and IMO the code is much easier to read. I've also added some
helpful comments.
This is just a clean-up I wrote while studying the code, and that has
been in my backlog for a while.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251381 91177308-0d34-0410-b5e6-96231b3b80d8
Use `getUnsignedMax` directly instead of special casing a wrapped
ConstantRange.
The previous code would have been "buggy" (and this would have been a
semantic change) if LLVM allowed !range metadata to denote full
ranges. E.g. in
%val = load i1, i1* %ptr, !range !{i1 1, i1 1} ;; == full set
ValueTracking would conclude that the high bit (IOW the only bit) in
%val was zero.
Since !range metadata does not allow empty or full ranges, this change
is just a minor stylistic improvement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251380 91177308-0d34-0410-b5e6-96231b3b80d8
When taking the remainder of a value divided by a constant, visitREM()
attempts to convert the REM to a longer but faster sequence of instructions.
This conversion calls combine() on a speculative DIV instruction. Commit
rL250825 may cause this combine() to return a DIVREM, corrupting nearby nodes.
Flow eventually hits unreachable().
This patch adds a test case and a check to prevent visitREM() from trying
to convert the REM instruction in cases where a DIVREM is possible.
See http://reviews.llvm.org/D14035
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251373 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously we maintained two separate switch statements that had to be kept in
sync. This patch merges them into a single switch.
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D14012
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251369 91177308-0d34-0410-b5e6-96231b3b80d8
LLVMSymbolizer::Options is mostly used in LLVMSymbolizer class anyway.
Let's keep their usage restricted to that class, especially given that
it's worth to move ModuleInfo to a different header, independent from
the symbolizer class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251363 91177308-0d34-0410-b5e6-96231b3b80d8
This is a preliminary step before adding another optimization
to PerformBITCASTCombine().
..and I really hope it's NFC this time!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251357 91177308-0d34-0410-b5e6-96231b3b80d8
