https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90414
--- Comment #2 from Matthew Malcomson <matmal01 at gcc dot gnu.org> --- (In reply to Richard Biener from comment #1) > (In reply to Matthew Malcomson from comment #0) > > Hello, > > > > I'm looking into how we can implement MTE in the compiler. > > What is MTE? It's an architecture extension, otherwise known as memory tagging or memtag. There's a high-level explanation in the link below, https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-a-profile-architecture-2018-developments-armv85a the instructions are introduced in Armv8.5-a. https://developer.arm.com/docs/ddi0596/latest/base-instructions-alphabetic-order I can't find a document describing *just* the MTE extension right now, but the gist is that memory regions can have associated tags, and accesses to those memory regions must be done with a pointer that has the corresponding tag in bits 56-59 inclusive. This is why the MTE extension will need to modify how the access is performed instead of just adding in a check before the access is done -- it needs to ensure that the pointer has the correct tag associated with the base object that it's trying to access. It's for the MTE extension that we would need the transformation below (so that the *_CHECK ifn can ensure the pointer has the relevant tag before access). > > ... > > 3) Would there be any obvious difficulties with a transformation of the > > form: > > _4 = big_arrayD.3771[num_3(D)] > > > > TO > > > > _6 = &big_arrayD.3771[num_3(D)]; > > _7 = HWASAN_CHECK(6, _6, 4, 4); > > _4 = *_7; > > > > Instead of > > _4 = big_arrayD.3771[num_3(D)] > > > > TO > > > > _6 = &big_arrayD.3771[num_3(D)]; > > ASAN_CHECK(6, _6, 4, 4); > > _4 = big_arrayD.3771[num_3(D)] > > > > which is what ASAN currently does. > > This new form would enable using MTE by allowing the check to modify the > > pointer that the access will be made with (so it can have have its tag). > > The "obvious" difficulties is that HWASAN_CHECK expansion needs to handle > expanding the actual memory reference. But that's only a slight > complication. > > Other complication is of course that it may pessimize optimization more > than the old approach.
