[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