This value was added to clang/Basic in D111566, but is only used during
codegen, where we can use the LLVM IR DataLayout instead. I noticed this
because the downstream CHERI targets would have to also set this value
for AArch64/RISC-V/MIPS. Instead of duplicating more information between
LLVM IR and Clang, this patch moves getTargetAddressSpace(QualType T) to
CodeGenTypes, where we can consult the DataLayout.
Details
- Reviewers
eandrews dylanmckay bader rjmccall - Group Reviewers
Restricted Project - Commits
- rGf3a17d059509: [clang] Avoid duplicating ProgramAddressSpace in TargetInfo. NFCI
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Functionally this looks ok to me. However I am not sure if CodeGenTypes is the 'right' place for this function to live, considering that other functions with similar functionality are in ASTContext - including overloads of getTargetAddressSpace( ). @erichkeane @aaron.ballman could you please take a look?
My view is that the parts that interact with LLVM IR should really live in CodeGen/ and not Basic/ or AST/. I will see how difficult it would be to move the remaining target (LLVM IR) address space handling code to CodeGen/
Yeah, I don't think there's a good reason for some of the address-space stuff that currently lives in Basic to be there instead of in CodeGen. Basic/AST need to understand what address spaces exist, their sizes, and what relationships they have with each other, and that's it.
Thanks for looking at this - does this mean you are happy for me to commit this change?
I think this is fine. Most of the patch is changing calls to getTargetAddressSpace to be internal to IRGen, which, as mentioned, I think is the right move.
I do think that if we're going to support multiple program address spaces (which seems to be a goal) that we'll eventually want an AST-level concept of the default program address space, but perpetuating the use of target ASes at the AST level isn't the right way to approach that, so this is still the right first step.