llvm dev - May 2020 - "Earlyclobber" but for a subset of the inputs

Hi Quentin,

> It sounds like you only need the earlyclobber description for the N, N
> variant.
> In other words, as long as you use different opcodes for widen-op NN and
> widen-op WN, you model exactly what you want.
>
> What am I missing?
>
we are using different opcodes for widen-op NN and widen-op WN.

My understanding is that not setting earlyclobber to the W, N variant would
allow the RegAlloc to do an allocation like this

W1 = widen-op W2, N3

but this is not correct in that target because W1 and N3 are of different
kind and W1 (being the group of registers N2, N3) overlaps N3.

If I understand earlyclobber semantics correctly, earlyclobber would
allocate the destination to something that doesn't overlap W2 and also
doesn't overlap N3. For instance

W3 = widen-op W2, N3

But because the dest is a W register the target's constraint only applies
to N3, not to W2, so the following should be OK (however RegAlloc would
never make such an assignment under earlyclobber)

W2 = widen-op W2, N3

In principle earlyclobber is always going to do allocations that are
correct for the target but there are a valid ones that will be missed.

Kind regards,

-- 
Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200505/d6a4a207/attachment.html>

Hi Roger,
> On May 4, 2020, at 11:37 PM, Roger Ferrer Ibáñez <rofirrim at
gmail.com> wrote:
> 
> Hi Quentin,
> 
> 
> It sounds like you only need the earlyclobber description for the N, N
variant.
> In other words, as long as you use different opcodes for widen-op NN and
widen-op WN, you model exactly what you want.
> 
> What am I missing?
> 
> we are using different opcodes for widen-op NN and widen-op WN.
> 
> My understanding is that not setting earlyclobber to the W, N variant would
allow the RegAlloc to do an allocation like this
> 
> W1 = widen-op W2, N3
Sorry I mixed up earlyclobber and tie-operand. For some reason I thought
earlyclobber could be set individually on the src operands to say that they
interfere with the definition...
That’s obviously wrong.

So yeah there isn’t anything in LLVM right now that conveys the semantic you
want.

If you’re really concerned that you would use too many registers, you can
either:
1. Add this concept to llvm 
2. Repair after regalloc

For #2, basically you don’t set any constraints in regalloc then after regalloc
(i.e., expand pseudo), you check if there are some overlapping and if so, you
change the allocation locally.
E.g.,
W1 = W2, N3
=>
N4 = copy N3
W1 = copy W2, N4
or
W3 = copy W2, N3
W1 = copy W3

Depending on what is the cheapest with respect to what registers are available
(you may have to spill).

Cheers,
-Quentin
> 
> but this is not correct in that target because W1 and N3 are of different
kind and W1 (being the group of registers N2, N3) overlaps N3.
> 
> If I understand earlyclobber semantics correctly, earlyclobber would
allocate the destination to something that doesn't overlap W2 and also
doesn't overlap N3. For instance
> 
> W3 = widen-op W2, N3
> 
> But because the dest is a W register the target's constraint only
applies to N3, not to W2, so the following should be OK (however RegAlloc would
never make such an assignment under earlyclobber)
> 
> W2 = widen-op W2, N3
> 
> In principle earlyclobber is always going to do allocations that are
correct for the target but there are a valid ones that will be missed.
> 
> Kind regards,
> 
> -- 
> Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200505/391f29f2/attachment.html>

Hi Quentin,

Thanks! I was worried I might be missing something very obvious. I'll look
into your suggestions.

Kind regards,

Missatge de Quentin Colombet <qcolombet at apple.com> del dia dt., 5 de
maig
2020 a les 19:59:
> Hi Roger,
>
> On May 4, 2020, at 11:37 PM, Roger Ferrer Ibáñez <rofirrim at
gmail.com>
> wrote:
>
> Hi Quentin,
>
>
>> It sounds like you only need the earlyclobber description for the N, N
>> variant.
>> In other words, as long as you use different opcodes for widen-op NN
and
>> widen-op WN, you model exactly what you want.
>>
>> What am I missing?
>>
>
> we are using different opcodes for widen-op NN and widen-op WN.
>
> My understanding is that not setting earlyclobber to the W, N variant
> would allow the RegAlloc to do an allocation like this
>
> W1 = widen-op W2, N3
>
>
> Sorry I mixed up earlyclobber and tie-operand. For some reason I thought
> earlyclobber could be set individually on the src operands to say that they
> interfere with the definition...
> That’s obviously wrong.
>
> So yeah there isn’t anything in LLVM right now that conveys the semantic
> you want.
>
> If you’re really concerned that you would use too many registers, you can
> either:
> 1. Add this concept to llvm
> 2. Repair after regalloc
>
> For #2, basically you don’t set any constraints in regalloc then after
> regalloc (i.e., expand pseudo), you check if there are some overlapping and
> if so, you change the allocation locally.
> E.g.,
> W1 = W2, N3
> =>
> N4 = copy N3
> W1 = copy W2, N4
> or
> W3 = copy W2, N3
> W1 = copy W3
>
> Depending on what is the cheapest with respect to what registers are
> available (you may have to spill).
>
> Cheers,
> -Quentin
>
>
> but this is not correct in that target because W1 and N3 are of different
> kind and W1 (being the group of registers N2, N3) overlaps N3.
>
> If I understand earlyclobber semantics correctly, earlyclobber would
> allocate the destination to something that doesn't overlap W2 and also
> doesn't overlap N3. For instance
>
> W3 = widen-op W2, N3
>
> But because the dest is a W register the target's constraint only
applies
> to N3, not to W2, so the following should be OK (however RegAlloc would
> never make such an assignment under earlyclobber)
>
> W2 = widen-op W2, N3
>
> In principle earlyclobber is always going to do allocations that are
> correct for the target but there are a valid ones that will be missed.
>
> Kind regards,
>
> --
> Roger Ferrer Ibáñez
>
>
>
-- 
Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200505/3cd450d9/attachment.html>