skatrak wrote: > Could this lead to mixing up allocas and heap allocations at the same > insertion point? It would be much better if all allocas came first and then > all heap allocations came second - IIRC this is why things were named to > refer to alloca insertion points - heap allocations were treated more like > regular code.
Yes, the approach I've implemented in this PR stack allows the creation of device shared memory allocations interleaved with regular allocas, depending on the order in which things end up being added. It's not a change really introduced by this PR itself, but I guess the argument renamings here would make it "official". > Is there a later LLVM pass that is smart enough to move all the allocas to > the start of the block? I don't know about this. However, I wasn't aware mixing allocas and heap allocations in the same block could cause issues, could you share an example where that would be problematic? I see the benefit of splitting allocations from initializations and other instructions, because it makes sure we don't accidentally try to access memory before it has been defined, but that's not something that would happen by interleaving heap allocation instructions (they're not supposed to access any potential sibling allocas). https://github.com/llvm/llvm-project/pull/154752 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
