[llvm] [RFC] Extend MemoryEffects to Support Target-Specific Memory Locations (PR #148650)

[Nikita Popov via llvm-commits]

nikic wrote:

> Hi @nikic ,
> 
> Thank you for your comments, I do have some extra notes.
> 
> My concern is that with Data being 32 bits and reserving 2 bits for each location, there are 16 memory locations available. There are 3 already being reserved to ArgMem, InaccessibleMem and Other. Now AArch64 is using 2(AArch64_FPRM and AArch64_ZA, I will probably expand to use for ZT0), if each target adds its own location it could be out of space with Data.
> 
> Any suggestion how to implement the Target Memory Location? The way it is implemented the Target Memory Locations for now is correct ? Should I change?

We could easily increase the size to 64 bits, which gives us 32 locations.

My primary concern with making this dependent on the backend is that I don't want to thread backend information through to every place that works with MemoryEffects.

However, I guess that generic code doesn't actually care about what a target-specific memory location refers to. So a possible approach would be to just reserve a fixed number of target-memory locations like `target1`, `target2`, `target3` etc. and then have the backend assign specific meanings to those locations. This can involve some support to register names for these memory locations, so they can be printed in a friendlier way. E.g. we could print them as `memory(target1: /*aarch64.fpmr*/ read)` or something, if the target information is available.

Does this sound reasonable to you?
 
> Another question, should we treat these extra locations as Inaccessible memory as well? So, should onlyAccessesInaccessibleMem() return true is any Target Memory Location is set.

That would make sense to me.

https://github.com/llvm/llvm-project/pull/148650