================
@@ -1444,15 +1444,16 @@ void clang::emitBackendOutput(CompilerInstance &CI,
CodeGenOptions &CGOpts,
// Verify clang's TargetInfo DataLayout against the LLVM TargetMachine's
// DataLayout.
- if (AsmHelper.TM) {
- std::string DLDesc = M->getDataLayout().getStringRepresentation();
- if (DLDesc != TDesc) {
+ if (AsmHelper.TM)
+ if (!AsmHelper.TM->isCompatibleDataLayout(M->getDataLayout()) ||
+ !AsmHelper.TM->isCompatibleDataLayout(DataLayout(TDesc))) {
+ std::string DLDesc = M->getDataLayout().getStringRepresentation();
----------------
AlexMaclean wrote:
I don't think it is a good idea to create a situation in which the datalayout
does not match the expected/actual AS of alloca instructions. One potential
issue with having an `A0` datalayout and addrspace 5 allocas could be that
various passes (including SDAG Legalization) could insert addrspace 0 allocas
based on the datalayout while our current lowering would expect them to be in
addrspace 5.
One way to avoid this kind of inconsistency is to update the datalayout in the
pass that updates the allocas (as you did originally). @efriedma-quic pointed
out that this is pretty weird and uncommon, but it didn't seem to create any
practical issues. Another option is to completely update everywhere to use A5.
This isn't totally new ground since this seems to be what AMDGPU does but it is
a really big change that I'm not sure what all the implications would be,
especially for out-of-tree uses. It seems like both options had pros/cons but I
would recommend that we choose either over a datalayout which doesn't match the
actual allocas.
https://github.com/llvm/llvm-project/pull/154814
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
