| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
This should fix a buildbot failure that occurred after r179977.
llvm-svn: 179978
|
| |
|
|
|
|
|
| |
This allows common sp-offsets to be part of the instruction and is
probably faster on modern CPUs too.
llvm-svn: 179977
|
| |
|
|
| |
llvm-svn: 179975
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Specifically:
1. Added checks that unwind is being properly added to various instructions.
2. Fixed the declaration/calling of objc_release to have a return type of void.
3. Moved all checks to precede the functions and added checks to ensure that the
checks would only match inside the specific function that we are attempting to
check.
llvm-svn: 179973
|
| |
|
|
|
|
| |
forwarding calls and does not touch calls which are not strictly forwarding (i.e. objc_retainBlock).
llvm-svn: 179972
|
| |
|
|
|
|
| |
clang-arc-used-intrinsic-removed-if-isolated.ll -> intrinsic-use-isolated.ll to match the other test file intrinsic-use.ll.
llvm-svn: 179971
|
| |
|
|
| |
llvm-svn: 179970
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With a little help from the frontend, it looks like the standard va_*
intrinsics can do the job.
Also clean up an old bitcast hack in LowerVAARG that dealt with
unaligned double loads. Load SDNodes can specify an alignment now.
Still missing: Calling varargs functions with float arguments.
llvm-svn: 179961
|
| |
|
|
| |
llvm-svn: 179960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This transformation will transform a conditional store with a preceeding
uncondtional store to the same location:
a[i] =
may-alias with a[i] load
if (cond)
a[i] = Y
into an unconditional store.
a[i] = X
may-alias with a[i] load
tmp = cond ? Y : X;
a[i] = tmp
We assume that on average the cost of a mispredicted branch is going to be
higher than the cost of a second store to the same location, and that the
secondary benefits of creating a bigger basic block for other optimizations to
work on outway the potential case were the branch would be correctly predicted
and the cost of the executing the second store would be noticably reflected in
performance.
hmmer's execution time improves by 30% on an imac12,2 on ref data sets. With
this change we are on par with gcc's performance (gcc also performs this
transformation). There was a 1.2 % performance improvement on a ARM swift chip.
Other tests in the test-suite+external seem to be mostly uninfluenced in my
experiments:
This optimization was triggered on 41 tests such that the executable was
different before/after the patch. Only 1 out of the 40 tests (dealII) was
reproducable below 100% (by about .4%). Given that hmmer benefits so much I
believe this to be a fair trade off.
I am going to watch performance numbers across the builtbots and will revert
this if anything unexpected comes up.
llvm-svn: 179957
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, when spilling 64-bit paired registers, an LDMIA with both
a FrameIndex and an offset was produced. This kind of instruction
shouldn't exist, and the extra operand was being confused with the
predicate, causing aborts later on.
This removes the invalid 0-offset from the instruction being
produced.
llvm-svn: 179956
|
| |
|
|
| |
llvm-svn: 179955
|
| |
|
|
| |
llvm-svn: 179954
|
| |
|
|
| |
llvm-svn: 179937
|
| |
|
|
| |
llvm-svn: 179930
|
| |
|
|
|
|
| |
parameter attribute 'returned', which is taken advantage of in target-independent tail call opportunity detection and in ARM call lowering (when placed on an integral first parameter).
llvm-svn: 179925
|
| |
|
|
|
|
| |
iterations of extractelement/insertelement indirection
llvm-svn: 179924
|
| |
|
|
| |
llvm-svn: 179906
|
| |
|
|
|
|
|
|
|
| |
The logic that actually compares the types considers pointers and integers the
same if they are of the same size. This created a strange mismatch between hash
and reality and made the test case for this fail on some platforms (yay,
test cases).
llvm-svn: 179905
|
| |
|
|
| |
llvm-svn: 179903
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When matching a compare with a subtract where the arguments of the compare are
swapped w.r.t. the arguments of the subtract, we need to negate the predicates
(or CR bit indices) of the users. This, however, is not the same as inverting
the predicate (negating LT -> GT, but inverting LT -> GE, for example). The ARM
backend seems to do this correctly, but when I adapted the code for the PPC
backend, I introduced an error in this logic.
Comparison optimization is now enabled again by default.
llvm-svn: 179899
|
| |
|
|
| |
llvm-svn: 179890
|
| |
|
|
|
|
| |
Based on the patch by David Nadlinger!
llvm-svn: 179889
|
| |
|
|
| |
llvm-svn: 179888
|
| |
|
|
|
|
| |
for a function that cannot produce a compact unwind encoding.
llvm-svn: 179887
|
| |
|
|
| |
llvm-svn: 179874
|
| |
|
|
|
|
|
|
| |
operand type to uimm16.
Patch by Vladimir Medic.
llvm-svn: 179872
|
| |
|
|
| |
llvm-svn: 179869
|
| |
|
|
|
|
| |
Fixes PR15791.
llvm-svn: 179859
|
| |
|
|
|
|
| |
Patch from Mihail Popa
llvm-svn: 179854
|
| |
|
|
| |
llvm-svn: 179850
|
| |
|
|
| |
llvm-svn: 179849
|
| |
|
|
|
|
|
|
|
| |
Thanks to Evgeniy Stepanov for reporting this.
It might be a good idea to add a command iterator abstraction to MachO.h, but
this fixes the bug for now.
llvm-svn: 179848
|
| |
|
|
| |
llvm-svn: 179847
|
| |
|
|
| |
llvm-svn: 179845
|
| |
|
|
|
|
| |
This reverts commit r179836 as it seems to have caused test failures.
llvm-svn: 179840
|
| |
|
|
|
|
|
|
|
|
| |
Adding another CU-wide list, in this case of imported_modules (since they
should be relatively rare, it seemed better to add a list where each element
had a "context" value, rather than add a (usually empty) list to every scope).
This takes care of DW_TAG_imported_module, but to fully address PR14606 we'll
need to expand this to cover DW_TAG_imported_declaration too.
llvm-svn: 179836
|
| |
|
|
| |
llvm-svn: 179830
|
| |
|
|
| |
llvm-svn: 179828
|
| |
|
|
| |
llvm-svn: 179825
|
| |
|
|
|
|
|
| |
AT&T dialect. Test case for r179804 as well.
rdar://13674398 and PR13340.
llvm-svn: 179813
|
| |
|
|
|
|
|
| |
This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do
I'm disabling this for now.
llvm-svn: 179807
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many PPC instructions have a so-called 'record form' which stores to a specific
condition register the result of comparing the result of the instruction with
zero (always as a signed comparison). For integer operations on PPC64, this is
always a 64-bit comparison.
This implementation is derived from the implementation in the ARM backend;
there are some differences because PPC condition registers are allocatable
virtual registers (although the record forms always use a specific one), and we
look for a matching subtraction instruction after the compare (but before the
first use) in addition to before it.
llvm-svn: 179802
|
| |
|
|
|
|
|
|
| |
available.
This pattern started popping up in vectorized min/max reductions.
llvm-svn: 179797
|
| |
|
|
|
|
| |
limitation that extract is promoted over a cast only if the cast has only one use.
llvm-svn: 179786
|
| |
|
|
|
|
| |
it has only 2 uses: one to promote the vector phi in a loop and the other use is an extract operation of one element at a constant location.
llvm-svn: 179783
|
| |
|
|
|
|
|
| |
We are still able to handle mixed endian objects by swapping one struct at a
time.
llvm-svn: 179778
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In X86FastISel::X86SelectStore(), improperly aligned stores are rejected and
handled by the DAG-based ISel. However, X86FastISel::X86SelectLoad() makes
no such requirement. There doesn't appear to be an x86 architectural
correctness issue with allowing potentially unaligned store instructions.
This patch removes this restriction.
Patch by Jim Stichnot.
llvm-svn: 179774
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A min/max operation is represented by a select(cmp(lt/le/gt/ge, X, Y), X, Y)
sequence in LLVM. If we see such a sequence we can treat it just as any other
commutative binary instruction and reduce it.
This appears to help bzip2 by about 1.5% on an imac12,2.
radar://12960601
llvm-svn: 179773
|
| |
|
|
|
|
| |
Fixes PR15748.
llvm-svn: 179757
|