doru1004 wrote:

> I think this looks pretty far off from how this should look. It's essentially 
> backwards from how I envision this working, and is subject to failure 
> depending on what optimizations happen to do. The behavior cannot be subject 
> to what the IR looks like after optimizations, and needs to be bound by what 
> is possible with the IR structural rules. A new address space needs to handle 
> all of the fundamentals, like i8/i16 load and store, and arbitrary address 
> captures. This also should have a defined addrspacecast rule (though it 
> probably should be poison).
> 
> In particular I don't understand having the late MIR pass introducing new 
> virtual registers. That's counter to the point? You're now still subject to 
> register allocator behavior, and you're doing a lowering type operation which 
> needs to maintain LiveIntervals.
> 
> I think this should look almost exactly like LDS lowering. The actual objects 
> would be global variables (not allocas). Those registers would then be 
> reserved, and removed from the allocation process. The addresses would be 
> lowered into index into that global. load/store would be lowered into a COPY 
> to/from the reserved physical registers. Access to variable address would 
> require a slightly trickier sequence

@arsenm the PR should now be closer to what you wanted. Let me know your 
thoughts.

https://github.com/llvm/llvm-project/pull/205435
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to