| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
This fixes PR24107.
llvm-svn: 242050
|
| |
|
|
|
|
|
|
|
| |
Enable partial and runtime loop unrolling for NVPTX backend via
TTI::UnrollingPreferences with a small threshold. This partially unrolls
small loops which are often unrolled by the PTX to SASS compiler
and unrolling earlier can be beneficial.
llvm-svn: 242049
|
| |
|
|
|
|
|
|
|
|
| |
Enable runtime unrolling for loops with unroll count metadata ("#pragma unroll N")
and a runtime trip count. Also, do not unroll loops with unroll full metadata if the
loop has a runtime loop count. Previously, such loops would be unrolled with a
very large threshold (pragma-unroll-threshold) if runtime unrolled happened to be
enabled resulting in a very large (and likely unwise) unroll factor.
llvm-svn: 242047
|
| |
|
|
| |
llvm-svn: 242046
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit serializes the fixed stack objects, including fixed spill slots.
The fixed stack objects are serialized using a YAML sequence of YAML inline
mappings. Each mapping has the object's ID, type, size, offset, and alignment.
The objects that aren't spill slots also serialize the isImmutable and isAliased
flags.
The fixed stack objects are a part of the machine function's YAML mapping.
Reviewers: Duncan P. N. Exon Smith
llvm-svn: 242045
|
| |
|
|
|
|
| |
Add another C++ 32-bit EH table test.
llvm-svn: 242044
|
| |
|
|
|
|
|
| |
This is a C++11 feature that both GCC and MSVC have supported as ane extension
long before C++11 was approved.
llvm-svn: 242042
|
| |
|
|
|
|
|
| |
Passes should never modify it, just use the const version. While there
reduce copying in LoopInterchange. No functional change intended.
llvm-svn: 242041
|
| |
|
|
|
|
|
|
|
|
| |
It had accidently accepted a symbol+offset value (and emitted
incorrect code for it, keeping only the offset part) instead of
properly reporting the constraint as invalid.
Differential Revision: http://reviews.llvm.org/D11039
llvm-svn: 242040
|
| |
|
|
|
|
|
|
|
| |
The two-address instruction pass will convert these back to v_mad_f32
if necessary.
Differential Revision: http://reviews.llvm.org/D11060
llvm-svn: 242038
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The 64/128-bit vector types are legal if NEON instructions are
available. However, there was no matching patterns for @llvm.cttz.*()
intrinsics and result in fatal error.
This commit fixes the problem by lowering cttz to:
a. ctpop((x & -x) - 1)
b. width - ctlz(x & -x) - 1
llvm-svn: 242037
|
| |
|
|
|
|
|
|
| |
Also, run thumb_rewrite.s tests in Thumb2 now that they pass.
Differential Revision: http://reviews.llvm.org/D11132
llvm-svn: 242036
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11131
llvm-svn: 242035
|
| |
|
|
|
|
|
|
|
| |
Also, add more Thumb2 ADD tests requested during review of
http://reviews.llvm.org/D11053.
Differential Revision: http://reviews.llvm.org/D11130
llvm-svn: 242034
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The iteration order within a member of DepCands is deterministic
and therefore we don't have to sort the accesses within a member.
We also don't have to copy the indices of the pointers into a
vector, since we can iterate over the members of the class.
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11145
llvm-svn: 242033
|
| |
|
|
|
|
| |
Sorry I missed it in the previous commit.
llvm-svn: 242032
|
| |
|
|
|
|
|
| |
Allowing that is probably a good idea, but currently we don't, so
this is dead code.
llvm-svn: 242031
|
| |
|
|
| |
llvm-svn: 242030
|
| |
|
|
| |
llvm-svn: 242028
|
| |
|
|
|
|
| |
We were already printing it for declarations, but not available_externally.
llvm-svn: 242027
|
| |
|
|
|
|
| |
The repros from PR23626 still fail.
llvm-svn: 242025
|
| |
|
|
|
|
|
|
|
|
|
|
| |
types.
In this patch I have only encoding. Intrinsics and DAG lowering will be in the next patch.
I temporary removed the old intrinsics test (just to split this patch).
Half types are not covered here.
Differential Revision: http://reviews.llvm.org/D11134
llvm-svn: 242023
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This at least saves compile time. I also encountered a case where
ephemeral values affect whether other variables are promoted, causing
performance issues. It may be a bug in LSR, but I didn't manage to
reduce it yet. Anyhow, I believe it's in general not worth considering
ephemeral values in LSR.
Reviewers: atrick, hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11115
llvm-svn: 242011
|
| |
|
|
| |
llvm-svn: 242008
|
| |
|
|
| |
llvm-svn: 242007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Register r12 ('ip') is used by GCC for this purpose
and hence is used here. As discussed on the GCC mailing
list, the register choice is an ABI issue and so
choosing the same register as GCC means
__builtin_call_with_static_chain is compatible.
A similar patch has just gone in the AArch64 backend,
so this is just the ARM counterpart, following the same
discussion.
Patch by Stephen Cross.
llvm-svn: 241996
|
| |
|
|
|
|
| |
(V)PMINSB is no different to the other (V)PMIN/(V)PMAX B/D/W instructions - it is fully commutable.
llvm-svn: 241994
|
| |
|
|
| |
llvm-svn: 241990
|
| |
|
|
|
|
|
|
|
|
| |
While the v4i32 shl operation is already vectorized using a cvttps2dq/pmulld pattern, the lshr/ashr opeations are still scalarized.
This patch adds vectorization support for non-uniform v4i32 shift operations - it splats constant shift amounts to allow them to use the immediate sse shift instructions, or extracts/zero-extends non-constant shift amounts. The individual results are then blended together.
Differential Revision: http://reviews.llvm.org/D11063
llvm-svn: 241989
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There is no suitable basic block to sink instructions in loops without
exits. The only way an instruction in a loop without exits can be used
is as an incoming value to a PHI. In such cases, the incoming block for
the corresponding value is unreachable.
This fixes PR24013.
Differential Revision: http://reviews.llvm.org/D10903
llvm-svn: 241987
|
| |
|
|
|
|
|
|
|
|
| |
r238842 added the TargetRecip system for controlling use of reciprocal
estimates for sqrt and division using a set of parameters that can be set by
the frontend. Clang now supports a sophisticated -mrecip option, and this will
allow that option to effectively control the relevant code-generation
functionality of the PPC backend.
llvm-svn: 241985
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the 'nest' attribute, which allows the static chain
register to be set for functions calls under non-Darwin PPC/PPC64 targets. r11
is the chain register (which the PPC64 ELF ABI calls the "environment
pointer"). For indirect calls under PPC64 ELFv1, this would normally be loaded
from the function descriptor, but providing an explicit 'nest' parameter will
override that process and use the value provided.
This allows __builtin_call_with_static_chain to work as expected on PowerPC.
llvm-svn: 241984
|
| |
|
|
|
|
|
|
|
|
|
| |
r236894 caused PR23626 (Clang miscompiles webkit's base64 decoder), and was
reverted in r237984. This reapplies the patch with an additional test case for
PR23626 and the associated fix (both scales and offsets in the
BasicAliasAnalysis::constantOffsetHeuristic should initially be zero).
Patch by Nick White, thanks!
llvm-svn: 241981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following functions are moved from the LoopVectorizer to VectorUtils:
- getGEPInductionOperand
- stripGetElementPtr
- getUniqueCastUse
- getStrideFromPointer
These used to be static functions in LoopVectorize, but will also be used by
the upcoming loop versioning LICM transformation.
Patch by Ashutosh Nema!
llvm-svn: 241980
|
| |
|
|
|
|
|
|
| |
This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis.
Differential Revision: http://reviews.llvm.org/D10398
llvm-svn: 241979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No in-tree alias analysis used this facility, and it was not called in
any particularly rigorous way, so it seems unlikely to be correct.
Note that one of the only stateful AA implementations in-tree,
GlobalsModRef is completely broken currently (and any AA passes like it
are equally broken) because Module AA passes are not effectively
invalidated when a function pass that fails to update the AA stack runs.
Ultimately, it doesn't seem like we know how we want to build stateful
AA, and until then trying to support and maintain correctness for an
untested API is essentially impossible. To that end, I'm planning to rip
out all of the update API. It can return if and when we need it and know
how to build it on top of the new pass manager and as part of *tested*
stateful AA implementations in the tree.
Differential Revision: http://reviews.llvm.org/D10889
llvm-svn: 241975
|
| |
|
|
| |
llvm-svn: 241971
|
| |
|
|
| |
llvm-svn: 241966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disallow all mutation of `MCSubtargetInfo` expect the feature bits.
Besides deleting the assignment operators -- which were dead "code" --
this restricts `InitMCProcessorInfo()` to subclass initialization
sequences, and exposes a new more limited function called
`setDefaultFeatures()` for use by the ARMAsmParser `.cpu` directive.
There's a small functional change here: ARMAsmParser used to adjust
`MCSubtargetInfo::CPUSchedModel` as a side effect of calling
`InitMCProcessorInfo()`, but I've removed that suspicious behaviour.
Since the AsmParser shouldn't be doing any scheduling, there shouldn't
be any observable change...
llvm-svn: 241961
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most loads and stores are derived from pointers derived from
a kernel argument load inserted during argument lowering.
This was just using the EntryToken chain for the argument loads,
and any users of these loads were also on the EntryToken chain.
Return the chain of the lowered argument load so that dependent loads
end up on the correct chain.
No test since I'm not aware of any case where this actually
broke.
llvm-svn: 241960
|
| |
|
|
|
|
|
|
| |
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D11005
llvm-svn: 241959
|
| |
|
|
|
|
|
| |
Integral class statics are handled oddly in MSVC, we don't need them
in this case, use an enum instead.
llvm-svn: 241958
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Force all creators of `MCSubtargetInfo` to immediately initialize it,
merging the default constructor and the initializer into an initializing
constructor. Besides cleaning up the code a little, this makes it clear
that the initializer is never called again later.
Out-of-tree backends need a trivial change: instead of calling:
auto *X = new MCSubtargetInfo();
InitXYZMCSubtargetInfo(X, ...);
return X;
they should call:
return createXYZMCSubtargetInfoImpl(...);
There's no real functionality change here.
llvm-svn: 241957
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove all calls to `MCSubtargetInfo::InitCPUSched()` and merge its body
into the only relevant caller, `MCSubtargetInfo::InitMCProcessorInfo()`.
We were only calling the former after explicitly calling the latter with
the same CPU; it's confusing to have both methods exposed.
Besides a minor (surely unmeasurable) speedup in ARM and X86 from
avoiding running the logic twice, no functionality change.
llvm-svn: 241956
|
| |
|
|
|
|
| |
Fixes PR24083
llvm-svn: 241955
|
| |
|
|
|
|
|
| |
No test since I'm not aware of any case where this will
end up being a different chain.
llvm-svn: 241954
|
| |
|
|
| |
llvm-svn: 241951
|
| |
|
|
|
|
|
|
|
|
|
| |
This in turn would sometimes introduce new cleanupblocks that didn't
previously exist. The uses were being introduced by SSA value demotion.
We actually want to *promote* uses of EH pointers and selectors, so I
added some spcecial casing to avoid demoting such instructions. This is
getting overly complicated, but hopefully we'll come along and delete it
in the new representation.
llvm-svn: 241950
|
| |
|
|
| |
llvm-svn: 241949
|
| |
|
|
|
|
|
|
|
|
| |
The motivation is to allow GatherAllAliases / FindBetterChain
to not give up on dependent loads of a pointer from constant memory.
This is important for AMDGPU, because most loads are pointers
derived from a load of a kernel argument from constant memory.
llvm-svn: 241948
|