Avoid another implicit conversion from MachineInstrBundleIterator to
MachineInstr*, this time in MachineInstrBuilder.h (this is in pursuit of
PR26753).
llvm-svn: 262118
This debug output distracts from the -debug-only=polly-scops output. As it is
rather verbose and only really needed for debugging the domain construction
I drop this output. The domain construction is meanwhile stable enough to
not require regular debugging.
llvm-svn: 262117
Take MachineInstr by reference instead of by pointer in SlotIndexes and
the SlotIndex wrappers in LiveIntervals. The MachineInstrs here are
never null, so this cleans up the API a bit. It also incidentally
removes a few implicit conversions from MachineInstrBundleIterator to
MachineInstr* (see PR26753).
At a couple of call sites it was convenient to convert to a range-based
for loop over MachineBasicBlock::instr_begin/instr_end, so I added
MachineBasicBlock::instrs.
llvm-svn: 262115
In case the underlying basepointer of a ScopArrayInfo object is moved to another
module while the scop is still processed is it necessary to free dependent
ScopArrayInfo objects as they might otherwise be looked accidentally when a
new llvm basepointer value is reassigned the very same memory location as the
llvm value that has been moved earlier.
This function is not yet used in Polly itself, but is useful for external users.
llvm-svn: 262113
Summary:
The PS4 linker seems to handle this fine.
Hi David, it seems that indeed most ELF linkers support
__{start,stop}_SECNAME, as our proprietary linker does as well.
This follows the pattern of r250679 w.r.t. the testing.
Maggie, Phillip, Paul: I've tested this with the PS4 SDK 3.5 toolchain
prerelease and it seems to work fine.
Reviewers: davidxl
Subscribers: probinson, phillip.power, MaggieYi
Differential Revision: http://reviews.llvm.org/D17672
llvm-svn: 262112
merged into a loop that was subsequently unrolled (or otherwise nuked).
In this case it can't merge in the ASTs for any remaining nested loops,
it needs to re-add their instructions dircetly.
The fix is very isolated, but I've pulled the code for merging blocks
into the AST into a single place in the process. The only behavior
change is in the case which would have crashed before.
This fixes a crash reported by Mikael Holmen on the list after r261316
restored much of the loop pass pipelining and allowed us to actually do
this kind of nested transformation sequenc. I've taken that test case
and further reduced it into the somewhat twisty maze of loops in the
included test case. This does in fact trigger the bug even in this
reduced form.
llvm-svn: 262108
with a prior UsingDecl -- those should not even really be found by the lookup
here, except that we use the same lookup results for two different checks, and
the other check needs them.
This happens to work in *almost all* cases, because either the lookup results
list the UsingDecl first (and the NonTag result gets replaced by something
else) or because the problematic declaration is a function (which causes us to
use different logic to detect conflicts). This can also be triggered from a
state only reachable through modules (where the name lookup results can contain
multiple UsingDecls in the same scope).
llvm-svn: 262105
Summary:
Without tree pruning clang has 2,667,552 points.
Wiht only dominators pruning: 1,515,586.
With both dominators & predominators pruning: 1,340,534.
Differential Revision: http://reviews.llvm.org/D17671
llvm-svn: 262103
Summary: The map modifier 'delete' is parser in c++ mode as a delete keyword, which requires special handling in the map clause parsing.
Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev
Subscribers: cfe-commits, fraggamuffin, caomhin
Differential Revision: http://reviews.llvm.org/D17629
llvm-svn: 262094
Combinations of suffixes that look useful actually are ignored;
complaining about them will avoid mistakes.
Differential Revision: http://reviews.llvm.org/D17587
llvm-svn: 262092
Most of this is fairly straight forward. Add handling for min/max via existing matcher utility and ConstantRange routines. Add handling for clamp by exploiting condition constraints on inputs.
Note that I'm only handling two constant ranges at this point. It would be reasonable to consider treating overdefined as a full range if the instruction is typed as an integer, but that should be a separate change.
Differential Revision: http://reviews.llvm.org/D17184
llvm-svn: 262085
Currently we always expand ISD::FNEG. For v4f32 and v2f64 vector types VSX has
native support for this opcode
Phabricator: http://reviews.llvm.org/D17647
llvm-svn: 262079
This patch causes the 3-stage build pipeline to only build a host compiler in the first stage, and to build all targets for subsequent stages. The host target is determined via the Native target specifier added in r262070.
llvm-svn: 262071
This allows a user to specify "Native" as a target when configuring LLVM. Native will resolve to the LLVM_NATIVE_ARCH, which is the target that supports code generation for the host.
llvm-svn: 262070
This is needed to connect dependencies between the LLVMgold plugin and the clang stage-2 builds due to limitations in ExternalProject_Add.
Patch by Mike Edwards
Differential Revision: http://reviews.llvm.org/D17655
llvm-svn: 262067
This is needed to build the gold plugin in multi-stage builds.
Patch by Mike Edwards
Differential Revision: http://reviews.llvm.org/D17655
llvm-svn: 262065
The intended effect of this patch in conjunction with:
http://reviews.llvm.org/rL259392http://reviews.llvm.org/rL260145
is that customers using the AVX intrinsics in C will benefit from combines when
the store mask is constant:
void mstore_zero_mask(float *f, __m128 v) {
_mm_maskstore_ps(f, _mm_set1_epi32(0), v);
}
void mstore_fake_ones_mask(float *f, __m128 v) {
_mm_maskstore_ps(f, _mm_set1_epi32(1), v);
}
void mstore_ones_mask(float *f, __m128 v) {
_mm_maskstore_ps(f, _mm_set1_epi32(0x80000000), v);
}
void mstore_one_set_elt_mask(float *f, __m128 v) {
_mm_maskstore_ps(f, _mm_set_epi32(0x80000000, 0, 0, 0), v);
}
...so none of the above will actually generate a masked store for optimized code.
Differential Revision: http://reviews.llvm.org/D17485
llvm-svn: 262064
Duncan P. N. Exon Smith