[PATCH] D138563: [IntrisicEmitter] Allow intrinsic types to be dependent on the data layout

David Chisnall via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 6 03:27:43 PST 2022


theraven added a comment.

I generally prefer the approach here.  Generality is good when necessary but a source of bugs when unnecessary.  For things like stack save and stack restore, the only valid address space is the address space used for the stack.  Allowing overloading adds more burden to the verifier (it must check that the address space matches) for no benefit that I can perceive.

I could see a benefit if we permitted allocas to exist in different address spaces, for architectures with more than one stack, but that would be a very invasive change to the IR and one that would require rethinking a lot of assumptions.

I'm less convinced on the {prog,global} versions, because we do currently permit globals and functions to exist in specific address spaces and I can imagine a system with multiple ROM banks with different addressing making use of that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138563/new/

https://reviews.llvm.org/D138563



More information about the llvm-commits mailing list