| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 173479
|
| |
|
|
|
|
|
|
| |
Only for integers, pointers, and vectors of those. No floats.
Instrumentation seems very heavy, and may need to be replaced
with some approximation in the future.
llvm-svn: 173452
|
| |
|
|
|
|
|
| |
This adds an !add(a, b) operator to tablegen; this will be used
to cleanup the PPC register definitions.
llvm-svn: 173445
|
| |
|
|
|
|
| |
If the sutraction of the higher 32 bit parts gives a 0 result, we need to do the store operation.
llvm-svn: 173437
|
| |
|
|
|
|
|
| |
Allow the strategy to select SchedDFS. Allow the results of SchedDFS
to affect initialization of the scheduler state.
llvm-svn: 173425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loops over instructions in the basic block or the use-def list of the
value, neither of which are really efficient when repeatedly querying
about values in the same basic block.
What's more, we already know that the CondBB is small, and so we can do
a much more efficient test by counting the uses in CondBB, and seeing if
those account for all of the uses.
Finally, we shouldn't blanket fail on any such instruction, instead we
should conservatively assume that those instructions are part of the
cost.
Note that this actually fixes a bug in the pass because
isUsedInBasicBlock has a really terrible bug in it. I'll fix that in my
next commit, but the fix for it would make this code suddenly take the
compile time hit I thought it already was taking, so I wanted to go
ahead and migrate this code to a faster & better pattern.
The bug in isUsedInBasicBlock was also causing other tests to test the
wrong thing entirely: for example we weren't actually disabling
speculation for floating point operations as intended (and tested), but
the test passed because we failed to speculate them due to the
isUsedInBasicBlock failure.
llvm-svn: 173417
|
| |
|
|
|
|
| |
interface and allow other strategies to select it.
llvm-svn: 173413
|
| |
|
|
|
|
|
|
| |
directive for the Mips assembler.
Contributer: Vladimir Medic
llvm-svn: 173407
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 173401
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Plug TTI into the speculation logic, giving it a real cost interface
that can be specialized by targets.
The goal here is not to be more aggressive, but to just be more accurate
with very obvious cases. There are instructions which are known to be
truly free and which were not being modeled as such in this code -- see
the regression test which is distilled from an inner loop of zlib.
Everywhere the TTI cost model is insufficiently conservative I've added
explicit checks with FIXME comments to go add proper modelling of these
cost factors.
If this causes regressions, the likely solution is to make TTI even more
conservative in its cost estimates, but test cases will help here.
llvm-svn: 173357
|
| |
|
|
|
|
|
|
|
|
| |
We use constant folding to see if an intrinsic evaluates to the same value as a
constant that we know. If we don't take the undefinedness into account we get a
value that doesn't match the actual implementation, and miscompiled code.
This was uncovered by Chandler's simplifycfg changes.
llvm-svn: 173356
|
| |
|
|
|
|
| |
of stage2 in a bootstrap. Still investigating....
llvm-svn: 173343
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that can be specialized by targets.
The goal here is not to be more aggressive, but to just be more accurate
with very obvious cases. There are instructions which are known to be
truly free and which were not being modeled as such in this code -- see
the regression test which is distilled from an inner loop of zlib.
Everywhere the TTI cost model is insufficiently conservative I've added
explicit checks with FIXME comments to go add proper modelling of these
cost factors.
If this causes regressions, the likely solution is to make TTI even more
conservative in its cost estimates, but test cases will help here.
llvm-svn: 173342
|
| |
|
|
|
|
|
| |
unfolded constant expressions rather than checking each one
independently.
llvm-svn: 173341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a cost fuction that seems both a bit ad-hoc and also poorly suited to
evaluating constant expressions.
Notably, it is missing any support for trivial expressions such as
'inttoptr'. I could fix this routine, but it isn't clear to me all of
the constraints its other users are operating under.
The core protection that seems relevant here is avoiding the formation
of a select instruction wich a further chain of select operations in
a constant expression operand. Just explicitly encode that constraint.
Also, update the comments and organization here to make it clear where
this needs to go -- this should be driven off of real cost measurements
which take into account the number of constants expressions and the
depth of the constant expression tree.
llvm-svn: 173340
|
| |
|
|
|
|
| |
the redzone)
llvm-svn: 173335
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow Mips16 routines to call Mips32 routines that have abi requirements
that either arguments or return values are passed in floating point
registers. This handles only the pic case. We have not done non pic
for Mips16 yet in any form.
The libm functions are Mips32, so with this addition we have a complete
Mips16 hard float implementation.
We still are not able to complete mix Mip16 and Mips32 with hard float.
That will be the next phase which will have several steps. For Mips32
to freely call Mips16 some stub functions must be created.
llvm-svn: 173320
|
| |
|
|
|
|
|
| |
This fixes some edge cases that we would get wrong with uint64_ts.
PR14986.
llvm-svn: 173289
|
| |
|
|
| |
llvm-svn: 173288
|
| |
|
|
|
|
|
|
|
| |
long gone."
This causes crashes during the build of compiler-rt during selfhost. Add a
testcase for coverage.
llvm-svn: 173279
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The requirements of the strong heuristic are:
* A Protector is required for functions which contain an array, regardless of
type or length.
* A Protector is required for functions which contain a structure/union which
contains an array, regardless of type or length. Note, there is no limit to
the depth of nesting.
* A protector is required when the address of a local variable (i.e., stack
based variable) is exposed. (E.g., such as through a local whose address is
taken as part of the RHS of an assignment or a local whose address is taken as
part of a function argument.)
llvm-svn: 173231
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SSPStrong applies a heuristic to insert stack protectors in these situations:
* A Protector is required for functions which contain an array, regardless of
type or length.
* A Protector is required for functions which contain a structure/union which
contains an array, regardless of type or length. Note, there is no limit to
the depth of nesting.
* A protector is required when the address of a local variable (i.e., stack
based variable) is exposed. (E.g., such as through a local whose address is
taken as part of the RHS of an assignment or a local whose address is taken as
part of a function argument.)
This patch implements the SSPString attribute to be equivalent to
SSPRequired. This will change in a subsequent patch.
llvm-svn: 173230
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
contain pointers that count backwards.
For example, this is the hot loop in BZIP:
do {
m = *--p;
*p = ( ... );
} while (--n);
llvm-svn: 173219
|
| |
|
|
| |
llvm-svn: 173204
|
| |
|
|
|
|
|
|
|
|
| |
- Add list of physical registers clobbered in pseudo atomic insts
Physical registers are clobbered when pseudo atomic instructions are
expanded. Add them in clobber list to prevent DAG scheduler to
mis-schedule them after these insns are declared side-effect free.
- Add test case from Michael Kuperstein <michael.m.kuperstein@intel.com>
llvm-svn: 173200
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the body does not use them and it appears the body has positional parameters.
This can cause unexpected results as in the added test case. As the darwin
version of gas(1) which only supported positional parameters, happened to
ignore the named parameters. Now that we want to support both styles of
macros we issue a warning in this specific case.
rdar://12861644
llvm-svn: 173199
|
| |
|
|
| |
llvm-svn: 173197
|
| |
|
|
|
|
|
|
|
| |
an expression. Currently this bug causes the line to be ignored in a
release build and an assert in a debug build.
rdar://13062484
llvm-svn: 173195
|
| |
|
|
| |
llvm-svn: 173181
|
| |
|
|
|
|
|
|
| |
rip-rel relocations will be off by one byte.
PR15040.
llvm-svn: 173176
|
| |
|
|
|
|
|
|
| |
ModuleID
This is done to avoid odd test failures, like the one fixed in r171243.
llvm-svn: 173163
|
| |
|
|
|
|
| |
Volatile bitfields can cause valid stores of uninitialized bits.
llvm-svn: 173153
|
| |
|
|
|
|
|
| |
allows for gvn to perform certain optimizations. Thus the runline should
only contain -objc-arc-aa, not the full -objc-arc.
llvm-svn: 173126
|
| |
|
|
| |
llvm-svn: 173120
|
| |
|
|
|
|
| |
Manish already fixed this test to work with NoTTI.
llvm-svn: 173110
|
| |
|
|
|
|
|
|
|
| |
(sub 0, (sext bool to A)) to (zext bool to A).
Patch by Muhammad Ahmad
Reviewed by Duncan Sands
llvm-svn: 173093
|
| |
|
|
| |
llvm-svn: 173086
|
| |
|
|
| |
llvm-svn: 173085
|
| |
|
|
| |
llvm-svn: 172987
|
| |
|
|
| |
llvm-svn: 172986
|
| |
|
|
| |
llvm-svn: 172985
|
| |
|
|
|
|
|
|
| |
It is not possible to distinguish 3r instructions from 2r / rus instructions
using only the fixed bits. Therefore if an instruction doesn't match the
2r / rus format try to decode it as a 3r instruction before returning Fail.
llvm-svn: 172984
|
| |
|
|
|
|
|
| |
On valgrind the processor is reported;
Host CPU: athlon-fx
llvm-svn: 172983
|
| |
|
|
|
|
|
|
|
| |
The optimization handles esoteric cases but adds a lot of complexity both to the X86 backend and to other backends.
This optimization disables an important canonicalization of chains of SEXT nodes and makes SEXT and ZEXT asymmetrical.
Disabling the canonicalization of consecutive SEXT nodes into a single node disables other DAG optimizations that assume
that there is only one SEXT node. The AVX mask optimizations is one example. Additionally this optimization does not update the cost model.
llvm-svn: 172968
|
| |
|
|
|
|
|
| |
We ignore the cpu frontend and focus on pipeline utilization. We do this because we
don't have a good way to estimate the loop body size at the IR level.
llvm-svn: 172964
|
| |
|
|
| |
llvm-svn: 172963
|
| |
|
|
|
|
| |
instead of 1 here.
llvm-svn: 172956
|
| |
|
|
| |
llvm-svn: 172941
|
| |
|
|
|
|
|
| |
We weren't encoding boolean constants correctly due to modeling boolean as a
signed type & then sign extending an i1 up to a byte & getting 255.
llvm-svn: 172926
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This separates the check for "too few elements to run the vector loop" from the
"memory overlap" check, giving a lot nicer code and allowing to skip the memory
checks when we're not going to execute the vector code anyways. We still leave
the decision of whether to emit the memory checks as branches or setccs, but it
seems to be doing a good job. If ugly code pops up we may want to emit them as
separate blocks too. Small speedup on MultiSource/Benchmarks/MallocBench/espresso.
Most of this is legwork to allow multiple bypass blocks while updating PHIs,
dominators and loop info.
llvm-svn: 172902
|