[PATCH] D64953: GlobalISel: Support physical register inputs in patterns
Daniel Sanders via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 30 15:19:21 PDT 2019
dsanders added inline comments.
================
Comment at: test/TableGen/gisel-physreg-input.td:36-37
+// GISEL-NEXT: GIM_CheckRegBankForClass, /*MI*/0, /*Op*/1, /*RC*/MyTarget::GPR32RegClassID,
+// GISEL-NEXT: // MIs[0] Operand 2
+// GISEL-NEXT: GIM_CheckType, /*MI*/0, /*Op*/2, /*Type*/GILLT_s32,
+// GISEL-NEXT: // (add:{ *:[i32] } GPR32:{ *:[i32] }:$src0, SPECIAL:{ *:[i32] }) => (ADD_PHYS:{ *:[i32] } GPR32:{ *:[i32] }:$src0)
----------------
I'm a bit surprised to see that there's no register bank check here. I would have expected specifying a register to be equivalent to specifying a register class containing a single register. I suppose it doesn't have to but it does mean that we can contradict the register bank selector decisions by inserting cross-bank copies it was unaware of.
================
Comment at: test/TableGen/gisel-physreg-input.td:48
+def ADD_PHYS : I<(outs GPR32:$dst), (ins GPR32:$src0),
+ [(set GPR32:$dst, (add GPR32:$src0, SPECIAL))]> {
+ let Uses = [SPECIAL];
----------------
FWIW, I'd prefer registers to be explicitly named. This mostly because of possibility of accidental cases of the FIXME below but it's also because I have a general preference for only having one way to specify a name.
================
Comment at: test/TableGen/gisel-physreg-input.td:52-54
+// Try using the name of the physreg in another operand FIXME: Does
+// this make any sense, or should it be an error? It ends up requiring
+// the two be the same operand.
----------------
I think this is fine so long as the user is choosing the names. I'm not keen on it when a generated name and a chosen name are the same.
================
Comment at: utils/TableGen/GlobalISelEmitter.cpp:832
+ /// A map of anonymouss physical registser operands defined by the matchers
+ /// that may be referenced by the renderers.
----------------
registser -> register
================
Comment at: utils/TableGen/GlobalISelEmitter.cpp:2319
+class CopyPhysRegRenderer : public OperandRenderer {
+protected:
----------------
Could you add a description comment to this class?
================
Comment at: utils/TableGen/GlobalISelEmitter.cpp:2517-2519
+ // TODO: This is encoded as a 64-bit element, but only 16 or 32-bits are
+ // really needed for a physical register reference. We can pack the
+ // register and flags in a single field.
----------------
Yeah, we really ought to compress the table with sleb/uleb where appropriate so that elements have a minimum size of 1 byte. All the common flags would easily fit into 1 byte, and physical register id is at most 3 bytes (when leb encoded) and will often be 1 byte.
================
Comment at: utils/TableGen/GlobalISelEmitter.cpp:3881-3882
+ // FIXME: Is this necessary? Seems to avoid problems with interactions with
+ // special WZR handling.
if (ChildRec->isSubClassOf("Register")) {
----------------
I don't think I understand this comment, it doesn't really give enough context to know why the necessity is in doubt or the problems it avoids
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D64953/new/
https://reviews.llvm.org/D64953
More information about the llvm-commits
mailing list