================
@@ -11594,47 +11594,26 @@ multiclass sve2_int_to_fp_upcvt<string asm, bits<2>
U, SDPatternOperator op> {
//===----------------------------------------------------------------------===//
// SVE ordered load/store
//===----------------------------------------------------------------------===//
-class sve_mem_z_acq_fill_inst<string mnemonic> :
- I<(outs ZPRAny:$Zt), (ins GPR64sp:$Rn, uimm8s32:$imm), mnemonic,
- "\t$Zt, [$Rn, $imm]", "", []>, Sched<[]> {
+class sve_mem_z_ordered_inst<string mnemonic, dag oops, dag iops,
+ bits<11> opc, bits<3> opc2> :
+ I<oops, iops, mnemonic, "\t$Zt, [$Rn, $imm]", "", []>, Sched<[]> {
----------------
MartinWehking wrote:
Ok, I'm not sure actually, if this change is a good idea. Is it ok to invent
this new opc template parameter in the first place?
I just remembered when creating these classes in the first place, I wanted to
keep it closer to the encoding fields.
There is no opc field as far as I can see.
I'm just wondering what makes more sense here, to favour a class representing
the fields more closely or to hollow it out for convenience?
I suppose the "opcode" itself are the fixed bit patterns, but I'm not sure
about that.
I suppose it's the latter based on other examples, but I thought it would still
be worth asking.
https://github.com/llvm/llvm-project/pull/231430
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
