When creating high MachineMemOperand for MSTORE/MLOAD we supply
it with the original PointerInfo, while the pointer itself had been incremented.
The patch adds the proper offset to the PointerInfo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325135 91177308-0d34-0410-b5e6-96231b3b80d8
Making a width of GEP Index, which is used for address calculation, to be one of the pointer properties in the Data Layout.
p[address space]:size:memory_size:alignment:pref_alignment:index_size_in_bits.
The index size parameter is optional, if not specified, it is equal to the pointer size.
Till now, the InstCombiner normalized GEPs and extended the Index operand to the pointer width.
It works fine if you can convert pointer to integer for address calculation and all registered targets do this.
But some ISAs have very restricted instruction set for the pointer calculation. During discussions were desided to retrieve information for GEP index from the Data Layout.
http://lists.llvm.org/pipermail/llvm-dev/2018-January/120416.html
I added an interface to the Data Layout and I changed the InstCombiner and some other passes to take the Index width into account.
This change does not affect any in-tree target. I added tests to cover data layouts with explicitly specified index size.
Differential Revision: https://reviews.llvm.org/D42123
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325102 91177308-0d34-0410-b5e6-96231b3b80d8
* Document most API's
* Delete a useless function call
* Fix a discrepancy between the single and multi-opcode variants of
getActionDefinitions().
The multi-opcode variant now requires that more than one opcode is requested.
Previously it acted much like the single-opcode form but unnecessarily
enforced the requirements of the multi-opcode form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325067 91177308-0d34-0410-b5e6-96231b3b80d8
Also make a drive-by-fix of a bug in the subregister scan code that
only triggers with an incomplete or otherwise very irregular machine
description.
rdar://problem/37404493
This re-applies r324972 with an early exit in the case of a complete
failure to make this commit NFC again as intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325041 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
If the and has an additional use we shouldn't invert it. That creates an additional instruction.
While there add a one use check to the transform above that looked similar.
Reviewers: spatel, RKSimon
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43225
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325019 91177308-0d34-0410-b5e6-96231b3b80d8
The bug has been lying dormant, but apparently was never exposed, until
after rL324941 because we didn't return the correct result
for shifts with undef operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325010 91177308-0d34-0410-b5e6-96231b3b80d8
Here are the number of additional debug values salvaged in a stage2
build of clang:
63 SALVAGE: MUL
1250 SALVAGE: SDIV
(No values were salvaged from `srem` instructions in this experiment,
but it's a simple case to handle so we might as well.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324976 91177308-0d34-0410-b5e6-96231b3b80d8
Here are the number of additional debug values salvaged in a stage2
build of clang:
1912 SALVAGE: ASHR
405 SALVAGE: LSHR
249 SALVAGE: SHL
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324975 91177308-0d34-0410-b5e6-96231b3b80d8
Also make a drive-by-fix of a bug in the subregister scan code that
only triggers with an incomplete or otherwise very irregular machine
description.
rdar://problem/37404493
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324972 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
creation of memcpys in the SafeStack pass to set the alignment of the destination object to
its stack alignment while separately setting the source byval arguments alignment to its
alignment.
Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. (rL323886, rL323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773, rL324774,
rL324781, rL324784 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.
Reference
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.htmlhttp://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
Reviewers: eugenis, bollu
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42710
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324955 91177308-0d34-0410-b5e6-96231b3b80d8
This started by noticing that scalar and vector types were producing different results with div ops in PR36305:
https://bugs.llvm.org/show_bug.cgi?id=36305
...but the problem is bigger. I couldn't keep it straight without a table, so I'm attaching that as a PDF to
the review. The x86 tests in undef-ops.ll correspond to that table.
Green means that instsimplify and the DAG agree on the result for all types.
Red means the DAG was returning undef when IR was not.
Yellow means the DAG was returning a non-undef result when IR returned undef.
This patch assumes that we're currently doing the right thing in IR.
Note: I couldn't find any problems with lowering vector constants as the code comments were warning,
but those comments were written long ago in rL36413 .
Differential Revision: https://reviews.llvm.org/D43141
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324941 91177308-0d34-0410-b5e6-96231b3b80d8
Armv8.1-A added an atomic load-clear instruction (which performs bitwise
and with the complement of it's operand), but not a load-and
instruction. Our current code-generation for atomic load-and always
inserts an MVN instruction to invert its argument, even if it could be
folded into a constant or another instruction.
This adds lowering early in selection DAG to convert a load-and
operation into an xor with -1 and a load-clear, allowing the normal DAG
optimisations to work on it.
To do this, I've had to add a new ISD opcode, ATOMIC_LOAD_CLR. I don't
see any easy way to do this with an AArch64-specific ISD node, because
the code-generation for atomic operations assumes the SDNodes are of
type AtomicSDNode.
I've left the old tablegen patterns in because they are still needed for
global isel.
Differential revision: https://reviews.llvm.org/D42478
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324908 91177308-0d34-0410-b5e6-96231b3b80d8
Add a common -trap-unreachable option, similar to the target
specific hexagon equivalent, which has been replaced. This
turns unreachable instructions into traps, which is useful for
debugging.
Differential Revision: https://reviews.llvm.org/D42965
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324880 91177308-0d34-0410-b5e6-96231b3b80d8
This reverses instcombine's demanded bits' transform which always tries to clear bits in constants.
As noted in PR35792 and shown in the test diffs:
https://bugs.llvm.org/show_bug.cgi?id=35792
...we can do better in codegen by trying to form -1. The x86 sub test shows a missed opportunity.
I did investigate changing instcombine's behavior, but it would be more work to change
canonicalization in IR. Clearing bits / shrinking constants can allow killing instructions,
so we'd have to figure out how to not regress those cases.
Differential Revision: https://reviews.llvm.org/D42986
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324839 91177308-0d34-0410-b5e6-96231b3b80d8
SelectionDAG::getBoolConstant was recently introduced. At the time I didn't know getConstTrueVal existed, but I think getBoolConstant is better as it will use the source VT to make sure it can properly detect floating point if it is configured differently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324832 91177308-0d34-0410-b5e6-96231b3b80d8
All uses conservatively assume in early exit case that it will be a
predecessor. Changing default removes checking code in all uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324797 91177308-0d34-0410-b5e6-96231b3b80d8
* Use uleb128 for code offsets in the LSDA call site table.
* Omit the TTBase offset if the type table is empty.
This change can reduce the size of the DWARF/Itanium LSDA by about half.
Patch by Ryan Prichard!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324750 91177308-0d34-0410-b5e6-96231b3b80d8
Rely on the assembler to finalize the layout of the DWARF/Itanium
exception-handling LSDA. Rather than calculate the exact size of each
thing in the LSDA, use assembler directives:
To emit the offset to the TTBase label:
.uleb128 .Lttbase0-.Lttbaseref0
.Lttbaseref0:
To emit the size of the call site table:
.uleb128 .Lcst_end0-.Lcst_begin0
.Lcst_begin0:
... call site table entries ...
.Lcst_end0:
To align the type info table:
... action table ...
.balign 4
.long _ZTIi
.long _ZTIl
.Lttbase0:
Using assembler directives simplifies the compiler and allows switching
the encoding of offsets in the call site table from udata4 to uleb128 for
a large code size savings. (This commit does not change the encoding.)
The combination of the uleb128 followed by a balign creates an unfortunate
dependency cycle that the assembler must sometimes resolve either by
padding an LEB or by inserting zero padding before the type table. See
PR35809 or GNU as bug 4029.
Patch by Ryan Prichard!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324749 91177308-0d34-0410-b5e6-96231b3b80d8
r314974 introduced insertion of DEBUG_VALUEs after
each redefinition of debug value register in the slot index range.
In case the instruction redefining the debug value register
was a terminator, machine verifier would complain since it
enforces the rule of no non-terminator instructions
following the first terminator.
Differential Revision: https://reviews.llvm.org/D42801
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324734 91177308-0d34-0410-b5e6-96231b3b80d8
When adding operands to machine instructions in case of
RegisterSDNodes, generate a COPY node in case the register class
does not match the one in the instruction definition.
Differental Revision: https://reviews.llvm.org/D35561
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324733 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The class contained arrays of two structures (DataArray and HashData).
These structures were in 1:1 correspondence, and one of them contained
pointers to the other (and *both* contained a "Name" field). By merging
these two structures into one, we can save a bit of space without
negatively impacting much of anything.
Reviewers: JDevlieghere, aprantl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43073
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324724 91177308-0d34-0410-b5e6-96231b3b80d8
Add verification for copies involving generic registers if they are
compatible - ie if it is a generic copy, then the types are the
same, and if a COPY b/w generic and target virtual register, then
the sizes should be the same. Only checks if there are no sub registers
involved for now.
https://reviews.llvm.org/D37775
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324696 91177308-0d34-0410-b5e6-96231b3b80d8
MBB.print wasn't printing it, but the MIRPrinter is printing it. The
goal is to unify that as much as possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324681 91177308-0d34-0410-b5e6-96231b3b80d8
This addresses review feedback for D42940. The topological sort is
slightly more expensive but it can now also detect cycles in the
dependencies and actually works correctly.
rdar://problem/37217988
Differential Review: https://reviews.llvm.org/D43036
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324677 91177308-0d34-0410-b5e6-96231b3b80d8
Many in SimplifySetCC and FoldSetCC try to create true or false constants. Some of them query getBooleanContents to figure out whether to use all ones or just 1 for true. But many places do not check and just use 1 without ensuring the VT has an i1 scalar type. Note sure if those places only trigger before type legalization so they only see an i1
type?
To cleanup the inconsistency and reduce some duplicated code, this patch adds a getBoolConstant method to SelectionDAG that takes are of querying getBooleanContents and doing the right thing.
Differential Revision: https://reviews.llvm.org/D43037
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324634 91177308-0d34-0410-b5e6-96231b3b80d8
We're passing the binary op that uses the load instead of the load.
Noticed by inspection. Not sure how to test this because this just prevents the introduction of an extend that will later be truncated and will probably be combined out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324568 91177308-0d34-0410-b5e6-96231b3b80d8
The truncate is being used to replace other users of of the load, but we checked that the load only has one use so there are no other uses to replace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324567 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of:
%bb.1: derived from LLVM BB %for.body
print:
bb.1.for.body:
Also use MIR syntax for MBB attributes like "align", "landing-pad", etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324563 91177308-0d34-0410-b5e6-96231b3b80d8
The truncate is only needed if the load has additional users. It used to get passed to extendSetCCUses so was created early, but that's no longer the case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324562 91177308-0d34-0410-b5e6-96231b3b80d8
We were calling a load LN0 but it came from N0.getOperand(0) so its really more like LN00 if we follow the name used in other places.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324561 91177308-0d34-0410-b5e6-96231b3b80d8
Alexander Ivchenko