This moves the code that handles stripping debug info intrinsic from
StripDebugInfo(Module) to StripDebugInfo(Function). The latter is
already walking every instructions so it makes sense to do it at the
same time.
This makes also stripDebugInfo(Function) as an API more useful: it
is really dropping every debug info in the Function.
Finally the existing code is trigerring an assertion when the Module
is not fully materialized.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268832 91177308-0d34-0410-b5e6-96231b3b80d8
This re-applies r268760, reverted in r268794.
Fixes http://llvm.org/PR27670
The original imp-defs assertion was way overzealous: forward all
implicit operands, except imp-defs of the new super-reg def (r268787
for GR64, but also possible for GR16->GR32), or imp-uses of the new
super-reg use.
While there, mark the source use as Undef, and add an imp-use of the
old source reg: that should cover any case of dead super-regs.
At the stage the pass runs, flags are unlikely to matter anyway;
still, let's be as correct as possible.
Also add MIR tests for the various interesting cases.
Original commit message:
Codesize is less (16) or equal (8), and we avoid partial
dependencies.
Differential Revision: http://reviews.llvm.org/D19999
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268831 91177308-0d34-0410-b5e6-96231b3b80d8
In case of COPY-like instruction we may be able to deduce that a certain
input is unused, based on the used lanes of the register defined by the
instruction.
This even works accross otherwise incompatible copies (no need to have
compatible lanemasks, completely unused operands are still completely
unused). It even makes sense to redo the analysis in this case since we
gained information for a case we previously stopped at because of the
incompatible masks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268815 91177308-0d34-0410-b5e6-96231b3b80d8
(this is resubmit of r268529 with minor refactoring. r268529 was reverted
at r268536 due a memory sanitizer failure. I have not been able to
reproduce that failure and I checked all the variable used in my change
but I could not spot an issue. I did some refactoring and see if it will
give a clearer hint)
Summary:
Currently, when checking if a stack is "BigStack" or not, it doesn't count into spills and arguments. Therefore, LLVM won't reserve spill slot for this actually "BigStack". This may cause scavenger failure.
Reviewers: rengolin
Subscribers: vitalybuka, aemerson, rengolin, tberghammer, danalbert, srhines, llvm-commits
Differential Revision: http://reviews.llvm.org/D19896
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268810 91177308-0d34-0410-b5e6-96231b3b80d8
Original Commit Message
Extend load/store type canonicalization to handle unordered operations
Extend the type canonicalization logic to work for unordered atomic loads and stores. Note that while this change itself is fairly simple and low risk, there's a reasonable chance this will expose problems in the backends by suddenly generating IR they wouldn't have seen before. Anything of this nature will be an existing bug in the backend (you could write an atomic float load), but this will definitely change the frequency with which such cases are encountered. If you see problems, feel free to revert this change, but please make sure you collect a test case.
Note that the concern about lowering is now much less likely. PR27490 proved that we already *were* mucking with the types of ordered atomics and volatiles. As a result, this change doesn't introduce as much new behavior as originally thought.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268809 91177308-0d34-0410-b5e6-96231b3b80d8
Again, fairly simple. Only change is ensuring that we actually copy the property of the load correctly. The aliasing legality constraints were already handled by the FRE patches. There's nothing special about unorder atomics from the perspective of the PRE algorithm itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268804 91177308-0d34-0410-b5e6-96231b3b80d8
ABIs like NaCl uses 32-bit addresses but have 64-bit frame.
The new register class reflects those constraints when choosing a
register class for a address access.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268796 91177308-0d34-0410-b5e6-96231b3b80d8
You'll note there are essentially no code changes here. Cross block FRE heavily reuses code from the block local FRE. All of the tricky parts were done as part of the previous patch and the refactoring that removed the original code duplication.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268775 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is the first in a small series teaching GVN to optimize unordered loads aggressively. This change just handles block local FRE because that's the simplest thing which lets me test MDA, and the AvailableValue pieces. Somewhat suprisingly, MDA appears fine and only a couple of small changes are needed in GVN.
Once this is in, I'll tackle non-local FRE and PRE. The former looks like a natural extension of this, the later will require a couple of minor changes.
Differential Revision: http://reviews.llvm.org/D19440
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268770 91177308-0d34-0410-b5e6-96231b3b80d8
Retrying r268550/r268751 which were reverted at r268577/r268765 due a memory sanitizer failure.
I have not been able to reproduce that failure, but I've taken another guess at fixing
the problem in this version of the patch and will watch for another failure.
Original commit message:
Unlike earlier similar fixes, we need to recalculate the branch weights
in this case.
Differential Revision: http://reviews.llvm.org/D19674
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268767 91177308-0d34-0410-b5e6-96231b3b80d8
Added support for sendmsg(MSG[, OP[, STREAM_ID]]) syntax
in s_sendmsg and s_sendmsghalt instructions.
The syntax matches the SP3 assembler/disassembler rules.
That is why implicit inputs (like M0 and EXEC) are not printed
to disassembly output anymore.
sendmsg(...) allows only known message types and attributes,
even if literals are used instead of symbolic names.
However, raw literal (without "sendmsg") still can be used,
and that allows for any 16-bit value.
Tests updated/added.
Differential Revision: http://reviews.llvm.org/D19596
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268762 91177308-0d34-0410-b5e6-96231b3b80d8
This should fix bot breakage caused by r268746:
[AArch64] Combine callee-save and local stack SP adjustment instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268752 91177308-0d34-0410-b5e6-96231b3b80d8
Retrying r268550 which was reverted at r268577 due a memory sanitizer failure.
I have not been able to reproduce that failure, but I've taken a guess at fixing
the problem in this version of the patch and will watch for another failure.
Original commit message:
Unlike earlier similar fixes, we need to recalculate the branch weights
in this case.
Differential Revision: http://reviews.llvm.org/D19674
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268751 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
If a function needs to allocate both callee-save stack memory and local
stack memory, we currently decrement/increment the SP in two steps:
first for the callee-save area, and then for the local stack area. This
changes the code to allocate them both at once at the very beginning/end
of the function. This has two benefits:
1) there is one fewer sub/add micro-op in the prologue/epilogue
2) the stack adjustment instructions act as a scheduling barrier, so
moving them to the very beginning/end of the function increases post-RA
scheduler's ability to move instructions (that only depend on argument
registers) before any of the callee-save stores
This change can cause an increase in instructions if the original local
stack SP decrement could be folded into the first store to the stack.
This occurs when the first local stack store is to stack offset 0. In
this case we are trading off one more sub instruction for one fewer sub
micro-op (along with benefits (2) and (3) above).
Reviewers: t.p.northover
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18619
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268746 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 47486d52454d60cdf6becc0b2efe533c73794380.
It broke calling OpenCL kernel from another kernel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268739 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Direct object emission has an initialization order problem where an
InitMCObjectFile is called after MipsTargetELFStreamer determines whether
PIC is enabled by default or not. There doesn't seem to be point that
initializes all cases so split the responsibility between
MipsTargetELFStreamer and MipsAsmPrinter.
Reviewers: sdardis
Subscribers: dsanders, llvm-commits, sdardis
Differential Revision: http://reviews.llvm.org/D19728
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268737 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
There seems to have been a misunderstanding as to the meaning of 'offset' in
the rules laid down by our ABI. The previous code believed that 'offset' meant
the offset within the section that the relocation is applied to. However, it
should have meant the offset from the symbol used in the relocation expression.
This patch adds two fields to ELFRelocationEntry and uses them to correct the
order of relocations for MIPS. These fields contain:
* The original symbol before shouldRelocateWithSymbol() is considered. This
ensures that R_MIPS_GOT16 is able to correctly distinguish between local and
external symbols, allowing us to tell whether %got() requires a matching
%lo() or not (local symbols require one, external symbols don't). It also
prevents confusing cases where the fuzzy matching rules cause things like
%hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s.
* The original offset before shouldRelocateWithSymbol() is considered. The
existing Addend field is always zero when the object uses in place addends
(because it's already moved it to the encoding) but MIPS needs to use the
original offset to ensure that the linker correctly calculates the carry-in
bit for %hi() and %got().
IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of
the table to ensure that the linker rejects the table (we're unable to report
such errors directly). The alternatives to this risk accidental matching
against inappropriate relocations which may silently compute incorrect values
due to an incorrect carry bit between the %lo() and %hi()/%got().
Reviewers: sdardis
Subscribers: dsanders, sdardis, rafael, llvm-commits
Differential Revision: http://reviews.llvm.org/D19718
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268733 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This stops it misidentifying unconditional branches as conditional branches
which fixes a -verify-machineinstrs error about exiting a function via fall through.
Reviewers: sdardis
Subscribers: dsanders, sdardis, llvm-commits
Differential Revision: http://reviews.llvm.org/D19864
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268731 91177308-0d34-0410-b5e6-96231b3b80d8
Allowing overriding the default ASAN shadow mapping offset with the
-asan-shadow-offset option, and allow zero to be specified for both offset and
scale.
Patch by Aaron Carroll <aaronc@apple.com>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268724 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Check calling convention in AMDGPUMachineFunction::isKernel
This will be used for AMDGPU_HSA_KERNEL symbol type in output ELF.
Also, in the future unused non-kernels may be optimized.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D19917
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268719 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This will be used for AMDGPU_HSA_KERNEL symbol type in output ELF.
Also, in the future unused non-kernels may be optimized.
For now, also accept SPIR_KERNEL for HCC frontend.
Also, add bitcode compatibility tests for missing calling conventions
except AVR_BUILTIN which doesn't have parse code.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, joker.eph, llvm-commits
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268717 91177308-0d34-0410-b5e6-96231b3b80d8
If we don't, values that aren't precisely representable in f16 could
be used as-is in a promoted f32 operation, which would produce
incorrect results.
AArch64 had the correct behavior; add a focused test.
Fixes http://llvm.org/PR26871
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268700 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We need to clean up CFG before assigning discriminator to minimize the impact of optimization on debug info.
Reviewers: davidxl, dblaikie, dnovillo
Subscribers: dnovillo, danielcdh, llvm-commits
Differential Revision: http://reviews.llvm.org/D19926
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268675 91177308-0d34-0410-b5e6-96231b3b80d8
