LLVM fork issues #386
Description
Attempting to enable MTE led me to realize that when IA2 is compiled in non-release mode we were not inserting our pointer tagging at all in at least some functions (such as the ia2_compartment_destructor_N functions). This does make sense as our logic lives inside an optimization pass (AArch64DeadRegisterDefinitions) that may not always be applied.
When passing -O2 or -O3, however, we run into a bunch of problems, starting with unhandled instructions. I've been trying to add support for more instructions, but I think we may need to step back a bit and reconsider how our changes fit into Clang's compilation pipeline.
Our changes assume each AArch64 MachineInstruction that counts as a load or store accepts its address in a particular register operand, but this does not seem to be true. For example, STRQui accepts its address in operand 1, but this operand is sometimes a register and sometimes an immediate such as %stack.0.shared_sections:
STRQui killed %9:fpr128, %stack.0.shared_sections, 0
I'm not sure whether this is referring to the result of an alloca (which, if we're tagging stack references, we'll need to tag) or something else. At the very least, we can't simply assume that the address operand is in a register.
It also appears that after optimizations some of the instructions are working with 32-bit quantities that we'll need to treat differently than inserting references to (64-bit) x18.
I wonder if it makes sense to revisit inserting our tagging logic at a different point in the compilation pipeline, or if we can make the necessary changes in a robust way where they are.
At the very least, we should avoid silently failing to insert tagging when compiling sans optimizations.