Add i16, i32, i64 imul machine instructions to the list of reassociation
candidates.
A new bit of logic is needed to handle integer instructions: they have an
implicit EFLAGS operand, so we have to make sure it's dead in order to do
any reassociation with integer ops.
Differential Revision: http://reviews.llvm.org/D11660
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243756 91177308-0d34-0410-b5e6-96231b3b80d8
This makes llvm-nm consistent with binutils nm on executables and DLLs.
For a vanilla hello world executable, the address of main should include
the default image base of 0x400000.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243755 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Favor the extended reg patterns over the shifted reg patterns that match
only the operand shift and not the full sign/zero extend and shift.
Reviewers: jmolloy, t.p.northover
Subscribers: mcrosier, aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D11569
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243753 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is a follow up from r240560 and is a step further into
mitigating the compile time performance issues in CaptureTracker.
By providing the CaptureTracker with a "cached ordered basic block"
instead of computing it every time, MemDepAnalysis can use this cache
throughout its calls to AA->callCapturesBefore, avoiding to recompute it
for every scanned instruction. In the same testcase used in r240560,
compile time is reduced from 2min to 30s.
This also fixes PR22348.
rdar://problem/19230319
Differential Revision: http://reviews.llvm.org/D11364
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243750 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This prevents vreg260 and D7 from being merged in:
%vreg260<def> = LDC1 ...
JAL <ga:@sin>, <regmask ... list not containing D7 ...>
%D7<def> = COPY %vreg260; ...
Doing so is not valid because the JAL clobbers the D7.
This fixes the almabench regression in the LLVM 3.7.0 release branch.
Reviewers: MatzeB
Subscribers: MatzeB, qcolombet, hans, llvm-commits
Differential Revision: http://reviews.llvm.org/D11649
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243745 91177308-0d34-0410-b5e6-96231b3b80d8
This is to fix an incorrect error when trying to initialize
DwarfNumbers with a !cast<int> of a bits initializer.
getValuesAsListOfInts("DwarfNumbers") would not see an IntInit
and instead the cast, so would give up.
It seems likely that this could be generalized to attempt
the convertInitializerTo for any type. I'm not really sure
why the existing code seems to special case the string cast cases
when convertInitializerTo seems like it should generally handle this
sort of thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243722 91177308-0d34-0410-b5e6-96231b3b80d8
For a modulo (reminder) operation,
clang -target armv7-none-linux-gnueabi generates "__modsi3"
clang -target armv7-none-eabi generates "__aeabi_idivmod"
clang -target armv7-linux-androideabi generates "__modsi3"
Android bionic libc doesn't provide a __modsi3, instead it provides a
"__aeabi_idivmod". This patch fixes the LLVM ARMISelLowering to generate
the correct call when ever there is a modulo operation.
Differential Revision: http://reviews.llvm.org/D11661
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243717 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243693 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243666 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243661 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243660 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243652 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243651 91177308-0d34-0410-b5e6-96231b3b80d8
Update the debug info in the check-lines because the change in r243638
introduced a constant initialization before the prologue's end as part
of a register spill.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243640 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243638 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243636 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Mips doesn't implement unw_getcontext() or libunwind::Registers_*::jumpto() yet
so we must disable libunwind for this release.
Reviewers: hans
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11563
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243633 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243616 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243613 91177308-0d34-0410-b5e6-96231b3b80d8
This was fallout from r243581. Turns out C++14 has make_reverse_iterator.
Thanks to Filipe and David for the quick fix suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243598 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids stack overflows when the the compiler does not perform tail call
elimination. Apparently this happens for MSVC with the /Ob2 switch which
may be used by external code including this header.
Reported by and based on a patch from Jean-Francois Riendeau.
Related to rdar://21900756
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243590 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243585 91177308-0d34-0410-b5e6-96231b3b80d8
Prevent all the unrelated LLVM options to appear in the -help output
by introducing a tool specific option category. As a drive-by improve
the wording of the help message.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243583 91177308-0d34-0410-b5e6-96231b3b80d8
