[PATCH] D127317: [AArch64][SME] Add ldr/str (fill/spill) intrinsics
    Bryan Chan via Phabricator via llvm-commits 
    llvm-commits at lists.llvm.org
       
    Wed Mar 29 09:47:47 PDT 2023
    
    
  
bryanpkc added inline comments.
================
Comment at: llvm/test/CodeGen/AArch64/SME/sme-intrinsics-stores.ll:289
+; CHECK-NEXT:    addvl x8, x0, #16
+; CHECK-NEXT:    str za[w12, 0], [x8]
+; CHECK-NEXT:    ret
----------------
sdesmalen wrote:
> bryanpkc wrote:
> > @david-arm How does the VL multiplier in the address operand affect the vector offset? Could you explain why `za[w12, 0]` through `za[w12, 15]` are selected for VL multipliers 0-15, but for all multipliers larger than 16, only `za[w12, 0]` is selected (`w12` remains zero in all cases)? I understand that ACLE intrinsics won't actually generate slice offsets larger than 15, but the behaviour of the LLVM intrinsics is confusing (as they do not accept an explicit slice offset argument).
> I'm not sure if this answers your question, but it seemed we had a fix for the stores that we hadn't pushed upstream yet. It avoids creating e.g. `str za[w12, 0], [x0, #15, mul vl]`, since the immediates must match up. The fix can be found here: D147136.
Thanks! I noticed that discrepancy between `LDR` and `STR` later yesterday too. But how the LLVM intrinsics are designed to work is still not clear to me. Determining the slice offset based on the addend in the address operand, and resetting the slice offset to 0 if the addend is larger than 256 bytes, seems rather arbitrary. Am I missing something?
Repository:
  rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127317/new/
https://reviews.llvm.org/D127317
    
    
More information about the llvm-commits
mailing list