arsenm wrote: > My reading is, it has to match the ultimate code generator. Middle end > optimization relies on it to improve the code.
The definition of "match" leaves room for interpretation, and it would be a better system if we allowed more dynamic configuration for some fields. However this conversation is off topic. This is not about whether the datalayout matches the target or not, but the interpretation of the datalayout. The A field does not assert anything about the content of the module. It does not assert that any alloca with a non-A valued alloca can be replaced with an A address space alloca. An alloca that does not match this address space is not invalid, and you cannot say anything about it https://github.com/llvm/llvm-project/pull/136865 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
