[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