[PATCH, V2 2/7] opcodes: aarch64: flags to denote subclasses of ldst insns

[Indu Bhagat]

On 6/6/24 09:50, Richard Earnshaw (lists) wrote:
> On 01/06/2024 08:34, Indu Bhagat wrote:
>> [New in V2]
>>   Notes to be addressed during review:
>>   - What about sme_size_12_bhs ? these are luti ops
> LUTI* don't touch memory, they look up values from with an SVE/SME register.
> 
>>   - what to do for ldadd ? Should these be F_LDST_LOAD ? But it is
>>     F_ARITH_ADD too ...
> These would be best treated as SWAP operations, I think, since they read and write the target memory location.  For SCFI I doubt they would be relevant, but it depends how far you want to go in the insn sub-classification.

Yeah, SWAP is more correct. And no, they are not relevant for SCFI: 
Using them for save/restore of callee-saved registers is not an expected 
pattern (or should I say its an infeasible pattern for save/restore of 
regs), so we simply ignore these instructions from ginsn generation.

For SCFI purposes, so far, it is known that we care a subset of iclasses:
  - addsub_ext
  - addsub_imm
  - movewide
  - ldst_imm9
  - ldst_pos
  - ldstpair_indexed
  - ldstpair_off
  - branch_imm
  - branch_reg
  - compbranch
  - testbranch
  - condbranch

[This may grow a little bit when SCFI adds support for PAUTH insns 
(still on the TODO list)].

I battled with that question for a bit : should all insns be 
sub-classified irrespective of what SCFI needs for now ? I tended 
towards a "yes", because future uses (other than SCFI) cannot be 
predicted. And since its at the level of insn specification, I tended 
towards a "Lets correctly sub-classify for all insns now".

Do you have a recommendation here ?

In general, the arm insn set so far has given in nicely to this sort of 
sub-classification. I think most of them can be cleanly sub-classified, 
with ldadd*/stadd* insns in iclass lse_atomic appearing as the only 
exception.

Thanks
Indu