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

Paul Walker via cfe-commits cfe-commits at lists.llvm.org
Mon Oct 27 08:40:42 PDT 2025


paulwalker-arm wrote:

> > @nikic Do you think it'll be reasonable to revert the changes to onlyAccessesInaccessibleMem and onlyAccessesInaccessibleOrArgMem and land the patch as is? That will temporarily break the link and make it easier to rollout the support for target_mem. Perhaps also adding a note to the LangRef saying the target_mem locations must not be used outside of internal testing?
> 
> Possibly -- could you please clarify what the steps after that would be?

I was thinking the following can be done in parallel:
1. Improve alias analysis so it better disambiguates between target memory locations.
2. Implement the location hierarchy you propose.
3. Improve the IR printing so that it scales better as the number of inaccessible/target locations increases.
4. Migrate intrinsic definitions to use IntrRead/IntrWrite and remove the more specialised options. NFC change.

When the first three tracks are complete we can start the process of using the target memory locations by extending (or adding) AArch64 fp8 intrinsics. This is the point where things become locked down and we need to worry about bitcode.

Of which, I've being pondering the bitcode issue for a week or so and have yet to convince myself there's a migration path for existing intrinsics (because a function may have inferred its memory affect based on its contents). As a minimum, given the context of the target memory location being target specific it means the bitcode handling also becomes target specific? However, even the worse case scenario of only being able to use the new locations for new intrinsics can work, I'd just rather be able to migrate the existing ones.

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


More information about the cfe-commits mailing list