| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 243695
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixing MinSize attribute handling was discussed in D11363.
This is a prerequisite patch to doing that.
The handling of OptSize when lowering mem* functions was broken
on Darwin because it wants to ignore -Os for these cases, but the
existing logic also made it ignore -Oz (MinSize).
The Linux change demonstrates a widespread problem. The backend
doesn't usually recognize the MinSize attribute by itself; it
assumes that if the MinSize attribute exists, then the OptSize
attribute must also exist.
Fixing this more generally will be a follow-on patch or two.
Differential Revision: http://reviews.llvm.org/D11568
llvm-svn: 243693
|
|
|
|
| |
llvm-svn: 243691
|
|
|
|
|
|
|
|
|
|
|
| |
This uncovered latent bugs previously:
http://reviews.llvm.org/D10403
...but it's time to try again because internal tests aren't finding more.
If time passes and no other bugs are reported, we can remove this cl::opt.
llvm-svn: 243687
|
|
|
|
|
|
| |
This patch enable DFSan memory transformation for aarch64 (39-bit VMA).
llvm-svn: 243684
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also provide the associated assertion when CodeGen starts.
Reviewers: echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11654
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243682
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction.
The patch changes the SLPVectorizer::vectorizeStores to choose the immediate
succeeding or preceding candidate for a store instruction when it has multiple
consecutive candidates. In this way it has better chance to find more slp
vectorization opportunities.
Differential Revision: http://reviews.llvm.org/D10445
llvm-svn: 243666
|
|
|
|
|
|
|
|
| |
I'm not sure what reasons the comment here could have
had for not setting these. Without these set, there is
an assertion hit during DWARF emission.
llvm-svn: 243661
|
|
|
|
|
|
|
|
|
|
|
| |
Copy implementation of applyFixup from AArch64 with AArch64 bits
ripped out.
Tests will be included with a later commit. Several other
problems must be fixed before binary debug info emission
will work.
llvm-svn: 243660
|
|
|
|
|
| |
Reviewers: Duncan P. N. Exon Smith
llvm-svn: 243659
|
|
|
|
| |
llvm-svn: 243658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Replace the switch on instruction opcode with a switch on register size.
This way we don't need to update the switch statement when we add new
SMRD variants.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11601
llvm-svn: 243652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This function is never called. isReallyTriviallyReMaterializable() is
the function that should be implemented instead.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11620
llvm-svn: 243651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This hidden option would disable code generation through FastISel by
default. It was removed from the available options and from the
Fast-ISel tests that required it in order to run the tests.
Reviewers: dsanders
Subscribers: qcolombet, llvm-commits
Differential Revision: http://reviews.llvm.org/D11610
llvm-svn: 243638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
materialization.
Summary:
Previously, we would sign-extend non-boolean negative constants and
zero-extend otherwise. This was problematic for PHI instructions with
negative values that had a type with bitwidth less than that of the
register used for materialization.
More specifically, ComputePHILiveOutRegInfo() assumes the constants
present in a PHI node are zero extended in their container and
afterwards deduces the known bits.
For example, previously we would materialize an i16 -4 with the
following instruction:
addiu $r, $zero, -4
The register would end-up with the 32-bit 2's complement representation
of -4. However, ComputePHILiveOutRegInfo() would generate a constant
with the upper 16-bits set to zero. The SelectionDAG builder would use
that information to generate an AssertZero node that would remove any
subsequent trunc & zero_extend nodes.
In theory, we should modify ComputePHILiveOutRegInfo() to consult
target-specific hooks about the way they prefer to materialize the
given constants. However, git-blame reports that this specific code
has not been touched since 2011 and it seems to be working well for every
target so far.
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11592
llvm-svn: 243636
|
|
|
|
|
|
|
|
|
| |
inline asm
Patch by: marina.yatsina@intel.com
Differential Revision: http://reviews.llvm.org/D11512
llvm-svn: 243630
|
|
|
|
|
|
|
| |
This is used by the AMD x86 OpenCL implementation
to change some ABI details on Windows and Linux.
llvm-svn: 243627
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason I was passing this vector by value in the constructor so that
I wouldn't have to copy when initializing the corresponding member but
then I forgot the std::move.
The use-case is LoopDistribution which filters the checks then
std::moves it to LoopVersioning's constructor. With this interface we
can avoid any copies.
llvm-svn: 243616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, we were passing the pointer partitions to LAA. Now, we get all
the checks from LAA and filter out the checks within partitions in
LoopDistribution.
This effectively concludes the steps to move filtering memchecks from
LAA into its clients. There is still some cleanup left to remove the
unused interfaces in LAA that still take PtrPartition.
(Moving this functionality to LoopDistribution also requires
needsChecking on pointers to be made public.)
llvm-svn: 243613
|
|
|
|
|
|
| |
dfsan), add a test
llvm-svn: 243611
|
|
|
|
|
|
| |
extend the memcmp fuzzer test
llvm-svn: 243603
|
|
|
|
|
|
|
|
| |
instruction-type check; NFC
This makes it simpler to add instruction types that don't depend on fast-math.
llvm-svn: 243596
|
|
|
|
|
|
|
| |
This is important for users of the C API who can't supply custom symbol
resolvers yet.
llvm-svn: 243589
|
|
|
|
|
|
|
|
| |
the other files that have the same typo. All comments, no functionality change! (Merely a "fuctionality" change.)
Bonus change to remove emacs major mode marker from SystemZMachineFunctionInfo.cpp because emacs already knows it's C++ from the extension. Also fix typo "appeary" in AMDGPUMCAsmInfo.h.
llvm-svn: 243585
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r243567, which ultimately reapplies r243563.
The fix here was to use std::enable_if for overload resolution. Thanks to David
Blaikie for lots of help on this, and for the extra tests!
Original commit message follows:
For cases where we needed a foreach loop in reverse over a container,
we had to do something like
for (const GlobalValue *GV : make_range(TypeInfos.rbegin(),
TypeInfos.rend())) {
This provides a convenience method which shortens this to
for (const GlobalValue *GV : reverse(TypeInfos)) {
There are 2 versions of this, with a preference to the rbegin() version.
The first uses rbegin() and rend() to construct an iterator_range.
The second constructs an iterator_range from the begin() and end() methods
wrapped in std::reverse_iterator's.
Reviewed by David Blaikie.
llvm-svn: 243581
|
|
|
|
|
|
|
| |
on suggestions. Currently the function is only used for inline purposes
and this is more descriptive for the use.
llvm-svn: 243578
|
|
|
|
|
|
|
|
| |
This patch improves the 32-bit target i64 constant matching to detect the shuffle vector splats that are introduced by i64 vector shift vectorization (D8416).
Differential Revision: http://reviews.llvm.org/D11327
llvm-svn: 243577
|
|
|
|
|
|
|
|
|
| |
It's potentially more efficient on Cyclone, and from the optimization guides &
schedulers looks like it has no effect on Cortex-A53 or A57. In general you'd
expect a MOV to be about the most efficient instruction with its semantics,
even though the official "UXTW" alias is really a UBFX.
llvm-svn: 243576
|
|
|
|
|
|
|
| |
This commit serializes the save and restore machine basic block references from
the machine frame information class.
llvm-svn: 243575
|
|
|
|
|
|
|
| |
This commit extracts the code that's used by the class 'MIRParserImpl' to parse
the machine basic block references into a new method named 'parseMBBReference'.
llvm-svn: 243572
|
|
|
|
|
|
|
|
| |
This patch vectorizes the v2i64/v4i64 ASHR shift operations - the last remaining integer vector shifts that are still being transferred to/from the scalar unit to be completed.
Differential Revision: http://reviews.llvm.org/D11439
llvm-svn: 243569
|
|
|
|
|
|
|
|
|
| |
This reverts commit r243563.
The GCC buildbots were extremely unhappy about this. Reverting while
we discuss a better way of doing overload resolution.
llvm-svn: 243567
|
|
|
|
|
|
| |
GEPOperator::getSourceElementType
llvm-svn: 243566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For cases where we needed a foreach loop in reverse over a container,
we had to do something like
for (const GlobalValue *GV : make_range(TypeInfos.rbegin(),
TypeInfos.rend())) {
This provides a convenience method which shortens this to
for (const GlobalValue *GV : reverse(TypeInfos)) {
There are 2 versions of this, with a preference to the rbegin() version.
The first uses rbegin() and rend() to construct an iterator_range.
The second constructs an iterator_range from the begin() and end() methods
wrapped in std::reverse_iterator's.
Reviewed by David Blaikie.
llvm-svn: 243563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls.
Summary:
returns_twice (most importantly, setjmp) functions are
optimization-hostile: if local variable is promoted to register, and is
changed between setjmp() and longjmp() calls, this update will be
undone. This is the reason why "man setjmp" advises to mark all these
locals as "volatile".
This can not be enough for ASan, though: when it replaces static alloca
with dynamic one, optionally called if UAR mode is enabled, it adds a
whole lot of SSA values, and computations of local variable addresses,
that can involve virtual registers, and cause unexpected behavior, when
these registers are restored from buffer saved in setjmp.
To fix this, just disable dynamic alloca and UAR tricks whenever we see
a returns_twice call in the function.
Reviewers: rnk
Subscribers: llvm-commits, kcc
Differential Revision: http://reviews.llvm.org/D11495
llvm-svn: 243561
|
|
|
|
|
|
|
| |
r242871 missed one place that should be guarded with isPhysicalReg. This patch
fixes that.
llvm-svn: 243555
|
|
|
|
| |
llvm-svn: 243554
|
|
|
|
| |
llvm-svn: 243553
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Making allowableAlignment() more accessible was suggested as a predecessor patch
for D10662, so I've pulled it into TargetLowering. This let's us remove 4 instances
of duplicate logic in LegalizeDAG.
There's a subtle functional change in the implementation: the existing
allowableAlignment() code was using getPrefTypeAlignment() when checking
alignment with the DataLayout and assumed that was fast. In this implementation,
we use getABITypeAlignment() and assume that is fast. See the TODO comment or the
discussion in the Phab review for future improvements in this implementation
(don't use the data layout at all).
There are no regression test changes from this difference, and I'm not sure how to
expose it via a test. I think we actually do want to provide the 'Fast' param when
checking this from DAGCombiner::MergeConsecutiveStores(). Ie, we shouldn't merge
stores if the new stores are not going to be fast. But that change will require
fixing allowsMisalignedMemoryAccess() overrides as noted in D10662.
Differential Revision: http://reviews.llvm.org/D10905
llvm-svn: 243549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ASan shadow on Android starts at address 0 for both historic and
performance reasons. This is possible because the platform mandates
-pie, which makes lower memory region always available.
This is not such a good idea on 64-bit platforms because of MAP_32BIT
incompatibility.
This patch changes Android/AArch64 mapping to be the same as that of
Linux/AAarch64.
llvm-svn: 243548
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11583
llvm-svn: 243546
|
|
|
|
|
|
| |
Previously successor selection was simply wrong.
llvm-svn: 243545
|
|
|
|
| |
llvm-svn: 243544
|
|
|
|
|
|
|
|
|
|
| |
sources"
Reported to Broke some internal tests: PR24303
This reverts commit r243486.
llvm-svn: 243540
|
|
|
|
|
|
|
|
| |
This lifts the somewhat arbitrary restriction on 3 OptSpecifiers.
Differential Revision: http://reviews.llvm.org/D11597
llvm-svn: 243539
|
|
|
|
|
|
|
| |
No functional change because "lsl #12" is actually encoded as 12, but one less
bug if someone ever decides to change that for the giggles.
llvm-svn: 243536
|
|
|
|
|
|
| |
been addressed. Also reverts r243389, which relied on this commit.
llvm-svn: 243527
|
|
|
|
|
|
| |
PR24299
llvm-svn: 243522
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given certain shuffle-vector masks, LLVM emits splat instructions
which splat the wrong bytes from the source register. The issue is
that the function PPC::isSplatShuffleMask() in PPCISelLowering.cpp
does not ensure that the splat pattern found is requesting bytes that
are aligned on an EltSize boundary. This patch detects this situation
as not a valid splat mask, resulting in a permute being generated
instead of a splat.
Patch and test case by Tyler Kenney, cleaned up a bit by me.
This is a simple bug fix that would be good to incorporate into 3.7.
llvm-svn: 243519
|
|
|
|
|
|
|
|
|
|
| |
This commit defines subtarget feature strict-align and uses it instead of
cl::opt -aarch64-strict-align to decide whether strict alignment should be
forced.
rdar://problem/21529937
llvm-svn: 243516
|