[PATCH] D45541: [globalisel] Update GlobalISel emitter to match new representation of extending loads
Daniel Sanders via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 11 16:08:48 PDT 2018
dsanders created this revision.
dsanders added reviewers: ab, aditya_nandakumar, bogner, rtereshin, volkan, rovka.
Herald added subscribers: kristof.beyls, javed.absar.
Previously, a extending load was represented at (G_*EXT (G_LOAD x)).
This had a few drawbacks:
- G_LOAD had to be legal for all sizes you could extend from, even if registers didn't naturally hold those sizes.
- All sizes you could extend from had to be allocatable just in case the extend went missing (e.g. by optimization).
- At minimum, G_*EXT and G_TRUNC had to be legal for these sizes. As we improve optimization of extends and truncates, this legality requirement would spread without considerable care w.r.t when certain combines were permitted.
- The SelectionDAG importer required some ugly and fragile pattern rewriting to translate patterns into this style.
This patch changes the representation to:
- (G_[SZ]EXTLOAD x)
- (G_LOAD x) any-extends when MMO.getSize() * 8 < ResultTy.getSizeInBits()
which resolves these issues by allowing targets to work entirely in their
native register sizes, and by having a more direct translation from
SelectionDAG patterns.
Each extending load can be lowered by the legalizer into separate extends
and loads, however a target that supports s1 will need the any-extending
load to extend to at least s8 since LLVM does not represent memory accesses
smaller than 8 bit. The legalizer can widenScalar G_LOAD into an
any-extending load but sign/zero-extending loads need help from something
else like a combiner pass. A follow-up patch that adds combiner helpers for
for this will follow.
The new representation requires that the MMO correctly reflect the memory
access so this has been corrected in a couple tests. I've also moved the
extending loads to their own tests since they are (mostly) separate opcodes
now. Additionally, the re-write appears to have invalidated two tests from
select-with-no-legality-check.mir since the matcher table no longer contains
loads that result in s1's and they aren't legal in AArch64 anymore.
Depends on https://reviews.llvm.org/D45540
Repository:
rL LLVM
https://reviews.llvm.org/D45541
Files:
include/llvm/CodeGen/GlobalISel/InstructionSelector.h
include/llvm/CodeGen/GlobalISel/InstructionSelectorImpl.h
include/llvm/Target/GlobalISel/SelectionDAGCompat.td
lib/Target/AArch64/AArch64InstructionSelector.cpp
lib/Target/AArch64/AArch64LegalizerInfo.cpp
test/CodeGen/AArch64/GlobalISel/legalize-extload.mir
test/CodeGen/AArch64/GlobalISel/legalize-sextload.mir
test/CodeGen/AArch64/GlobalISel/legalize-zextload.mir
test/CodeGen/AArch64/GlobalISel/select-atomicrmw.mir
test/CodeGen/AArch64/GlobalISel/select-cmpxchg.mir
test/CodeGen/AArch64/GlobalISel/select-extload.mir
test/CodeGen/AArch64/GlobalISel/select-load.mir
test/CodeGen/AArch64/GlobalISel/select-sextload.mir
test/CodeGen/AArch64/GlobalISel/select-with-no-legality-check.mir
test/CodeGen/AArch64/GlobalISel/select-zextload.mir
utils/TableGen/GlobalISelEmitter.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D45541.142089.patch
Type: text/x-patch
Size: 45431 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180411/0bd86c9a/attachment.bin>
More information about the llvm-commits
mailing list