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

[Amara Emerson via llvm-commits]

Phabricator doesn't seem to be sending to commits list, re-sending manually:

Hi all,

There are good questions here which we'll enumerate and answer
individually once we send out a new RFC to llvm-dev.

The reason that we didn't send out a new RFC to the list and instead
sent patches was because the basic idea of our SVE implementation was
fundamentally unchanged in terms the modified llvm::VectorType. The
other elements of our implementation didn't affect this core concept,
e.g. whether we used an instruction like elementcount or our new
vscale constant to deal with runtime vector lengths, likewise with the
stepvector constant vs seriesvector instruction.

To clarify again, from the compiler's perspective we can assume that
the VL is constant but unknown. If you have any other questions ping
them to us and we'll try to answer them as part of the new RFC.

Amara

On 22 May 2017 at 10:43, Amara Emerson <amara.emerson at gmail.com> wrote:
> Phabricator doesn't seem to be sending to commits list, re-sending manually:
>
> Hi all,
>
> There are good questions here which we'll enumerate and answer
> individually once we send out a new RFC to llvm-dev.
>
> The reason that we didn't send out a new RFC to the list and instead
> sent patches was because the basic idea of our SVE implementation was
> fundamentally unchanged in terms the modified llvm::VectorType. The
> other elements of our implementation didn't affect this core concept,
> e.g. whether we used an instruction like elementcount or our new
> vscale constant to deal with runtime vector lengths, likewise with the
> stepvector constant vs seriesvector instruction.
>
> To clarify again, from the compiler's perspective we can assume that
> the VL is constant but unknown. If you have any other questions ping
> them to us and we'll try to answer them as part of the new RFC.
>
> Amara
>
> On 21 May 2017 at 23:41, Renato Golin via Phabricator via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits