shiltian wrote: > 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
If I understand correctly, you're suggesting that there's no reliable way for the middle end to determine which address space an alloca will ultimately end up in, aside from cases where it's already in, unless it pulls that information directly from the backend, like what `InferAddressSpacePass` does. The data layout itself doesn't assert anything: first, it doesn't necessarily *match* the final code generator; and second, even if it does, the `A` field in the data layout doesn't necessarily guarantee or assert it. @nikic @efriedma-quic what do you think? 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
