This is an archive of the discontinued LLVM Phabricator instance.

[MC][AArch64] Fail if x18 is reserved and used
AbandonedPublic

Authored by evgeny777 on Apr 22 2020, 8:56 AM.

Details

Summary

This helps to auto-verify assembly files when project is built with -ffixed-x18

Diff Detail

Event Timeline

evgeny777 created this revision.Apr 22 2020, 8:56 AM

I'm not sure what rule you're using to justify this. Even if x18 is "reserved", assembly is allowed to use it for whatever purpose it's reserved for.

@efriedma From AArch64GenSubtargetInfo.inc:

{ "reserve-x18", "Reserve X18, making it unavailable as a GPR", AArch64::FeatureReserveX18, { { { 0x0ULL, 0x0ULL, 0x0ULL, } } } },

I thought it makes sense to error on using x18 to identify places when it's clobbered which otherwise has to be done with disassembling an image.

The "reserved" bit means that the compiler isn't supposed to use it as a general-purpose register, not that the code isn't allowed to touch it at all. Take, for example, the use of x18 on Android. x18 is reserved there, but the compiler actually uses the register in some cases: when shadow-call-stack is enabled, x18 points to the address of the shadow stack, and the compiler uses it to lower the prologue/epilogue of functions. So with this change, code on Android fails to compile with -save-temps.

If you have some policy that assembly in certain files isn't allowed to access x18, you need to enforce that some other way. We could add a new mechanism to enforce it at compile-time, I guess, but I'm not sure it would carry its weight. Like you noted, it's straightforward to scan the generated binary for instructions that reference x18.

evgeny777 abandoned this revision.Apr 23 2020, 11:22 AM

Well, this makes sense. Also I've encountered with cases when asm proc uses X18 is like a callee saved register which doesn't prevent shadow call stack runtime from working properly. Calling this off.