arsenm added a comment. In D64931#1622039 <https://reviews.llvm.org/D64931#1622039>, @lebedev.ri wrote:
> In D64931#1622038 <https://reviews.llvm.org/D64931#1622038>, @akhuang wrote: > > > @lebedev.ri The test case datalayout strings were changed because somewhere > > llvm asserts that the string in the IR matches the backend datalayout. I > > don't know why I wasn't getting the assert error now, but I think they'll > > all have to be changed > > > Can you post a reproducer? > > In D64931#1622038 <https://reviews.llvm.org/D64931#1622038>, @akhuang wrote: > > > if we change the X86 datalayout? > > > I think this is precisely what was discussed in replies to RFC - this > hardcodes these address spaces, > and thus either makes them unavaliable for other front-ends and/or forces > them to use them with Precisely Same Meaning. Address space have backend defined semantics, and aren’t really reserved for front end use. I think the fact that non-0 address spaces on X86 codegen the same as address space 0 and could be used for something by a front end is an accident of how SelectionDAG is implemented. If X86 wants to reserve address space ranges for frontend use, that would need to be decided and documented. You don’t necessarily get the current behavior for free in GlobalISel since pointer types are distinct, so this would specifically need to be implemented. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64931/new/ https://reviews.llvm.org/D64931 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
