| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
They had a separate RUN line already, so may as well be in a separate file.
llvm-svn: 179988
|
| |
|
|
|
|
|
| |
Arguments after the fixed arguments never use the floating point
registers.
llvm-svn: 179987
|
| |
|
|
| |
llvm-svn: 179986
|
| |
|
|
|
|
| |
Don't ignore the high 32 bits of the immediate.
llvm-svn: 179985
|
| |
|
|
|
|
| |
Patch by Loïc Jaquemet.
llvm-svn: 179984
|
| |
|
|
|
|
| |
'returned'
llvm-svn: 179983
|
| |
|
|
|
|
|
| |
This is an edge case that can happen if we modify a chain of multiple selects.
Update all operands in that case and remove the assert. PR15805.
llvm-svn: 179982
|
| |
|
|
|
|
| |
Mips backend.
llvm-svn: 179981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is the temptation to make this tranform dependent on target information as
it is not going to be beneficial on all (sub)targets. Therefore, we should
probably do this in MI Early-Ifconversion.
This reverts commit r179957. Original commit message:
"SimplifyCFG: If convert single conditional stores
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: 179980
|
| |
|
|
|
|
| |
of system include directories with extern "C" semantics.
llvm-svn: 179979
|
| |
|
|
|
|
| |
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: 179976
|
| |
|
|
| |
llvm-svn: 179975
|
| |
|
|
|
|
|
|
| |
with multiple users.
We did not terminate the switch case and we executed the search routine twice.
llvm-svn: 179974
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.
llvm-svn: 179969
|
| |
|
|
|
|
| |
NumPeeps and make sure that Changed is set to true.
llvm-svn: 179968
|
| |
|
|
| |
llvm-svn: 179967
|
| |
|
|
| |
llvm-svn: 179966
|
| |
|
|
| |
llvm-svn: 179965
|
| |
|
|
|
|
| |
large multi-level nested if statement.
llvm-svn: 179964
|
| |
|
|
|
|
|
|
|
|
| |
progress.
This will make it clearer when we are actually resetting a sequence's progress
vs just changing state. This is an important distinction because the former case
clears any pointers that we are tracking while the later does not.
llvm-svn: 179963
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Still to do here:
- we have a collection of syntactic accepts-invalids to diagnose
- support non-PODs in VLAs, including dynamic initialization /
destruction
- runtime checks (and throw std::bad_array_length) for bad bound
- support VLA capture by reference in lambdas
- properly support VLAs in range-based for (don't recompute bound)
llvm-svn: 179962
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 179959
|
| |
|
|
|
|
|
|
|
|
|
| |
Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default initializer.
There's an additional complication here: because the default initializer can
refer to the initialized object via its 'this' pointer, we need to make sure
that 'this' points to the right thing within the evaluation.
llvm-svn: 179958
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
done.
llvm-svn: 179953
|
| |
|
|
| |
llvm-svn: 179952
|
| |
|
|
| |
llvm-svn: 179951
|
| |
|
|
| |
llvm-svn: 179950
|
| |
|
|
| |
llvm-svn: 179949
|
| |
|
|
|
|
| |
keyword case statements to be consistent with r179119
llvm-svn: 179948
|
| |
|
|
| |
llvm-svn: 179947
|
| |
|
|
|
|
| |
we currently relax 'operator new' calls which didn't come from new-expressions.
llvm-svn: 179946
|
| |
|
|
| |
llvm-svn: 179945
|
| |
|
|
| |
llvm-svn: 179944
|
| |
|
|
| |
llvm-svn: 179943
|
| |
|
|
| |
llvm-svn: 179942
|
| |
|
|
|
|
| |
a trailing return type in that class's body.
llvm-svn: 179941
|
| |
|
|
|
|
|
|
| |
I think it's almost impossible to fold atomic fences profitably under
LLVM/C++11 semantics. As a result, this is now unused and just
cluttering up the target interface.
llvm-svn: 179940
|
| |
|
|
| |
llvm-svn: 179939
|