[llvm-dev] RFC: Allowing scalable vectors in structs to support multiple return values from intrinsics

[Chris Lattner via llvm-dev]

> On Jan 7, 2021, at 5:26 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>> If you want to avoid verifier changes, the token type already gives you what you want: it is opaque, cannot be loaded and stored or phid, and can serve as a "value multiplexer". You could invent new intrinsics to extract the values you need. The source of a token cannot be obscured, so lowering can always look through a token operand, find the source, and link up the correct SDValue in codegen. The downside is that all this solution would be opaque to the mid-level optimizers. They already understand insertvalue and extractvalue. So, I don't think this is a good way to go, but it's worth considering.
>> 
>> I think, if we all agree that first class aggregates that can be loaded, stored, and phi'd, were a historical design mistake, then your original proposed solution is a step in the direction of removing FCA support.
>> 
>> I wonder if, in the future, it would be possible to auto-upgrade IR that contains these FCA operations by splitting them into scalar operations, and we could make the verifier reject all of these undesired operations.
> +1 to this goal.  Getting there might be tricky, and take a while, but definite +1 to the direction.  

Yeah I agree with Phillip, this would be a great direction.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210107/d80d44ed/attachment.html>