[PATCH] D32737: [Constants][SVE] Represent the runtime length of a scalable vector

[Renato Golin via Phabricator via llvm-commits]

rengolin added a comment.

In https://reviews.llvm.org/D32737#760473, @chandlerc wrote:

> Put differently, this patch makes sense *once* we clearly have consensus on llvm-dev. So far, the only thread I can find did not reach any meaningful consensus. Notably, none of the code generator people were heavily contributing to that thread, and there remain large unmentioned technical concerns (stack spills, alloca size, etc)


I agree. I'm glad I pushed this further, and I think we should get a proper discussion in the list.

In my mind, the previous discussion was "good enough", because all my questions were answered and I saw that other people weren't complaining much (so I assumed everyone was happy).

When you reported on the actual status I could see that I was probably inside a bubble. Initially, the idea was to start slow and "cross bridges when we get there", but changing the IR is really serious.

Graham,

I think we'll need an RFC that goes beyond vscale. We need to understand how constants are handles, as well as scalar evolution, spills, stacks etc. Not to work on the patches or even publish them now, just to understand a few cases in IR.

It would be easier to see the proposal, and then have a counter-proposal using intrinsics, to see how things will look like.

I know ARM was initially reluctant to use intrinsics, but as I said before on previous reviews, they allow us to model the behaviour before any hard changes to IR. If we can't reach a consensus now, it'd probably be better to go that way for now and change as it becomes clearer what to do in IR.

In the long run, I still think we should support scalable vectors native in IR, but that can wait until everyone understands the actual semantics.

cheers,
--renato


https://reviews.llvm.org/D32737