On 4/15/25 9:21 AM, Richard Sandiford wrote:
Indu Bhagat <indu.bha...@oracle.com> writes:
Store Allocation Tags (st2g) is an Armv8.5-A memory tagging (MTE)
instruction. It stores an allocation tag to two tag granules of memory.
TBD:
- Not too sure what is the best way to generate the st2g yet; A
subsequent patch will emit them in one of the target hooks.
Regarding the previous thread about this:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668671.html
Apologies for this one again slipping through the cracks.
and your question about whether all types of store tag instructions
should be volatile: if we went for that approach, then yeah, I think so.
As I mentioned there, I don't think we should use (unspec ...) memory
addresses.
But thinking more about it: can we guarantee that GCC will only use
these instruction patterns with base registers that are aligned to
16 bytes? If so, then perhaps an alternative would be to model
them as read-modify-write operations to the whole granule (even though
the actual instructions leave normal memory untouched and only change
the tags). That is, rather than:
I think so. Each stack var is assigned a granule of its own (16-bytes);
for alloca, we align explicitly; and each pointer is based off the SP
(which is also 16-byte aligned for AAPCS64). IIRC, FEAT_MTE* are
available in AArch64 only.
BTW, the aarch64.md file has this comment for stg:
";; STG doesn't align the address but aborts with alignment fault
;; when the address is not 16-byte aligned."
Just curious: the same should be true for all MTE load/store tag
instructions, isnt it ? I cant seem to find the above specific
information in the ARM MTE instruction specification "Arm Architecture
Reference Manual for A-profile architecture."...
gcc/ChangeLog:
* config/aarch64/aarch64.md (st2g): New definition.
---
gcc/config/aarch64/aarch64.md | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 0c7aebb838cd..d3223e275c51 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -8475,6 +8475,26 @@
[(set_attr "type" "memtag")]
)
+;; ST2G updates allocation tags for two memory granules (i.e. 32 bytes) at
+;; once, without zero initialization.
+(define_insn "st2g"
+ [(set (mem:QI (unspec:DI
+ [(plus:DI (match_operand:DI 1 "register_operand" "rk")
+ (match_operand:DI 2 "aarch64_granule16_simm9" "i"))]
+ UNSPEC_TAG_SPACE))
+ (and:QI (lshiftrt:DI (match_operand:DI 0 "register_operand" "rk")
+ (const_int 56)) (const_int 15)))
+ (set (mem:QI (unspec:DI
+ [(plus:DI (match_dup 1)
+ (match_operand:DI 3 "aarch64_granule16_simm9" "i"))]
+ UNSPEC_TAG_SPACE))
+ (and:QI (lshiftrt:DI (match_dup 0)
+ (const_int 56)) (const_int 15)))]
+ "TARGET_MEMTAG && (INTVAL (operands[2]) - 16 == INTVAL (operands[3]))"
+ "st2g\\t%0, [%1, #%2]"
+ [(set_attr "type" "memtag")]
+)
+
...this, we could do:
(set (match_operand:OI 0 "aarch64_granule_memory_operand" "+<new constraint>")
(unspec_volatile:OI
[(match_dup 0)
(match_operand:DI 1 "register_operand" "rk")]
UNSPECV...))
Using OImode (256 bytes) indicates that two full granules are affected
by the store, but that no other memory is affected. The (match_dup 0)
read indicates that this store does not kill any previous store to the
same 256 bytes (since the contents of normal memory don't change).
The unspec_volatile should ensure that nothing tries to remove the
store as dead (which would especially be a problem when clearing tags).
Using a single memory operand for the whole instruction has the advantage
of only requiring one offset to be represented, rather than having both
operands 2 and 3 in the original pattern. It also copes more easily
with cases where the offset is zero for the first or second address,
since no (plus ...) should be present in that case.
Thanks,
Richard
