[llvm-dev] RFC: Allowing scalable vectors in structs to support multiple return values from intrinsics
Chris Lattner via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 7 22:10:22 PST 2021
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev