llvm dev - Jun 2017 - Ok with mismatch between dead-markings in BUNDLE and bundled instructions?

Not sure if I could follow everything in this discussion regarding subregisters.
But I think the problem posted by Mikael just happened to involve subregisters,
and the discussions about subregisters is confusing when it comes to Mikaels
original question/problem.

I think that the bundle could look something like this just as well:

     BUNDLE %vreg1<def,dead>
       * %vreg1<def> = add %vreg2, %vreg3
       * call @foo, %vreg1<internal-use>

No subregisters involved.
%vreg1 is dead after the bundle.
%vreg1 is not dead when defined at the "add", because it is used later
in the same bundle.

Should perhaps the %vreg1 not be included in the BUNDLE head at all here?
(but shouldn't the BUNDLE head be a summary of what is going on inside the
bundle, so leaving out information about %vreg1 being defined seems wrong)

To me it seems wrong to add "dead" to the def of %vreg1 at the add
(considering the internal-use).
Maybe that even answers the question that the "mismatch" between
dead-markings should be OK.
Or would it be OK to mark %vreg1 as dead at the add, even though we have a later
internal-use?

Regards,
Björn
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> Quentin Colombet via llvm-dev
> Sent: den 28 juni 2017 00:02
> To: Matthias Braun <mbraun at apple.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] Ok with mismatch between dead-markings in
> BUNDLE and bundled instructions?
> 
> 
> > On Jun 27, 2017, at 2:51 PM, Matthias Braun via llvm-dev <llvm-
> dev at lists.llvm.org> wrote:
> >
> >
> >> On Jun 27, 2017, at 2:44 PM, Krzysztof Parzyszek via llvm-dev
<llvm-
> dev at lists.llvm.org> wrote:
> >>
> >> On 6/27/2017 4:35 PM, Quentin Colombet via llvm-dev wrote:
> >>> Yeah I was reading this as “only the non-touched part are
dead”, and
> that’s what I’d like to see in the representation longer. Obviously, the
> register is not dead as a whole here :)
> >>
> >> I think that having two defs for the same register, one dead and
one not
> dead simply doesn't make sense. We already assume that a register is
live if
> at least a part of it is live, so if it's "dead", it should
mean that the whole thing
> is dead.
> > Without subregister I would agree. However with subregisters and
aliases
> in play you can express more situations. Like for example:
> >
> >    %rax<dead>, %eax = ...
> >
> > could mean the instruction writes the full rax register but we are
only
> gonna read eax later.
> 
> That sounds like an alias to:
> %rax<def-undef, subeax> = …
> 
> Which sounds fine. Though I am not suggesting we want to move to this
> dead model for such situation.
> 
> > That said I am not sure whether we actually need it, and if llvm works
that
> way today. Given how subtle all of this is there is also a high danger that
we
> won't get the bahviour consistent.
> 
> I agree that consistent behavior is important and I also think we probably
> cannot model what we want with the current representation. What I would
> like to see if that we don’t sit on potentially useful information, like
this part
> of the register is dead, because it is convenient implementation-wise. I am
> not saying that’s what you're suggesting!
> I agree that at the end of the day we want something that works and that is
> understandable. To me having the semantic of dead being this can be killed
if
> the instruction does not have side effects sounded easy enough to
> understand.
> 
> What is your proposal for the semantic?
> 
> (IIRC the dead flag is required for values that are never used and the
> proposed fix somehow goes against that.)
> 
> >
> > - Matthias
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Oh wait, vreg1 is indeed used.
Yeah, having a dead flag here sounds wrong.
> On Jun 28, 2017, at 2:28 AM, Björn Pettersson A <bjorn.a.pettersson at
ericsson.com> wrote:
> 
> Not sure if I could follow everything in this discussion regarding
subregisters. But I think the problem posted by Mikael just happened to involve
subregisters, and the discussions about subregisters is confusing when it comes
to Mikaels original question/problem.
> 
> I think that the bundle could look something like this just as well:
> 
>     BUNDLE %vreg1<def,dead>
>       * %vreg1<def> = add %vreg2, %vreg3
>       * call @foo, %vreg1<internal-use>
> 
> No subregisters involved.
> %vreg1 is dead after the bundle.
> %vreg1 is not dead when defined at the "add", because it is used
later in the same bundle.
> 
> Should perhaps the %vreg1 not be included in the BUNDLE head at all here?
> (but shouldn't the BUNDLE head be a summary of what is going on inside
the bundle, so leaving out information about %vreg1 being defined seems wrong)
> 
> To me it seems wrong to add "dead" to the def of %vreg1 at the
add (considering the internal-use).
> Maybe that even answers the question that the "mismatch" between
dead-markings should be OK.
> Or would it be OK to mark %vreg1 as dead at the add, even though we have a
later internal-use?
> 
> Regards,
> Björn
> 
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
>> Quentin Colombet via llvm-dev
>> Sent: den 28 juni 2017 00:02
>> To: Matthias Braun <mbraun at apple.com>
>> Cc: llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] Ok with mismatch between dead-markings in
>> BUNDLE and bundled instructions?
>> 
>> 
>>> On Jun 27, 2017, at 2:51 PM, Matthias Braun via llvm-dev <llvm-
>> dev at lists.llvm.org> wrote:
>>> 
>>> 
>>>> On Jun 27, 2017, at 2:44 PM, Krzysztof Parzyszek via llvm-dev
<llvm-
>> dev at lists.llvm.org> wrote:
>>>> 
>>>> On 6/27/2017 4:35 PM, Quentin Colombet via llvm-dev wrote:
>>>>> Yeah I was reading this as “only the non-touched part are
dead”, and
>> that’s what I’d like to see in the representation longer. Obviously,
the
>> register is not dead as a whole here :)
>>>> 
>>>> I think that having two defs for the same register, one dead
and one not
>> dead simply doesn't make sense. We already assume that a register
is live if
>> at least a part of it is live, so if it's "dead", it
should mean that the whole thing
>> is dead.
>>> Without subregister I would agree. However with subregisters and
aliases
>> in play you can express more situations. Like for example:
>>> 
>>>   %rax<dead>, %eax = ...
>>> 
>>> could mean the instruction writes the full rax register but we are
only
>> gonna read eax later.
>> 
>> That sounds like an alias to:
>> %rax<def-undef, subeax> = …
>> 
>> Which sounds fine. Though I am not suggesting we want to move to this
>> dead model for such situation.
>> 
>>> That said I am not sure whether we actually need it, and if llvm
works that
>> way today. Given how subtle all of this is there is also a high danger
that we
>> won't get the bahviour consistent.
>> 
>> I agree that consistent behavior is important and I also think we
probably
>> cannot model what we want with the current representation. What I would
>> like to see if that we don’t sit on potentially useful information,
like this part
>> of the register is dead, because it is convenient implementation-wise.
I am
>> not saying that’s what you're suggesting!
>> I agree that at the end of the day we want something that works and
that is
>> understandable. To me having the semantic of dead being this can be
killed if
>> the instruction does not have side effects sounded easy enough to
>> understand.
>> 
>> What is your proposal for the semantic?
>> 
>> (IIRC the dead flag is required for values that are never used and the
>> proposed fix somehow goes against that.)
>> 
>>> 
>>> - Matthias
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Oh wait, vreg1 is indeed used.
> Yeah, having a dead flag here sounds wrong.
I mean on the instruction itself.
On the bundle, that’s debatable. That would fit the semantic “if no side effect
you can kill it” (here there is side effect, we define other vregs).
> 
>> On Jun 28, 2017, at 2:28 AM, Björn Pettersson A <bjorn.a.pettersson
at ericsson.com> wrote:
>> 
>> Not sure if I could follow everything in this discussion regarding
subregisters. But I think the problem posted by Mikael just happened to involve
subregisters, and the discussions about subregisters is confusing when it comes
to Mikaels original question/problem.
>> 
>> I think that the bundle could look something like this just as well:
>> 
>>    BUNDLE %vreg1<def,dead>
>>      * %vreg1<def> = add %vreg2, %vreg3
>>      * call @foo, %vreg1<internal-use>
>> 
>> No subregisters involved.
>> %vreg1 is dead after the bundle.
>> %vreg1 is not dead when defined at the "add", because it is
used later in the same bundle.
>> 
>> Should perhaps the %vreg1 not be included in the BUNDLE head at all
here?
>> (but shouldn't the BUNDLE head be a summary of what is going on
inside the bundle, so leaving out information about %vreg1 being defined seems
wrong)
>> 
>> To me it seems wrong to add "dead" to the def of %vreg1 at
the add (considering the internal-use).
>> Maybe that even answers the question that the "mismatch"
between dead-markings should be OK.
>> Or would it be OK to mark %vreg1 as dead at the add, even though we
have a later internal-use?
>> 
>> Regards,
>> Björn
>> 
>>> -----Original Message-----
>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On
Behalf Of
>>> Quentin Colombet via llvm-dev
>>> Sent: den 28 juni 2017 00:02
>>> To: Matthias Braun <mbraun at apple.com>
>>> Cc: llvm-dev at lists.llvm.org
>>> Subject: Re: [llvm-dev] Ok with mismatch between dead-markings in
>>> BUNDLE and bundled instructions?
>>> 
>>> 
>>>> On Jun 27, 2017, at 2:51 PM, Matthias Braun via llvm-dev
<llvm-
>>> dev at lists.llvm.org> wrote:
>>>> 
>>>> 
>>>>> On Jun 27, 2017, at 2:44 PM, Krzysztof Parzyszek via
llvm-dev <llvm-
>>> dev at lists.llvm.org> wrote:
>>>>> 
>>>>> On 6/27/2017 4:35 PM, Quentin Colombet via llvm-dev wrote:
>>>>>> Yeah I was reading this as “only the non-touched part
are dead”, and
>>> that’s what I’d like to see in the representation longer.
Obviously, the
>>> register is not dead as a whole here :)
>>>>> 
>>>>> I think that having two defs for the same register, one
dead and one not
>>> dead simply doesn't make sense. We already assume that a
register is live if
>>> at least a part of it is live, so if it's "dead", it
should mean that the whole thing
>>> is dead.
>>>> Without subregister I would agree. However with subregisters
and aliases
>>> in play you can express more situations. Like for example:
>>>> 
>>>>  %rax<dead>, %eax = ...
>>>> 
>>>> could mean the instruction writes the full rax register but we
are only
>>> gonna read eax later.
>>> 
>>> That sounds like an alias to:
>>> %rax<def-undef, subeax> = …
>>> 
>>> Which sounds fine. Though I am not suggesting we want to move to
this
>>> dead model for such situation.
>>> 
>>>> That said I am not sure whether we actually need it, and if
llvm works that
>>> way today. Given how subtle all of this is there is also a high
danger that we
>>> won't get the bahviour consistent.
>>> 
>>> I agree that consistent behavior is important and I also think we
probably
>>> cannot model what we want with the current representation. What I
would
>>> like to see if that we don’t sit on potentially useful information,
like this part
>>> of the register is dead, because it is convenient
implementation-wise. I am
>>> not saying that’s what you're suggesting!
>>> I agree that at the end of the day we want something that works and
that is
>>> understandable. To me having the semantic of dead being this can be
killed if
>>> the instruction does not have side effects sounded easy enough to
>>> understand.
>>> 
>>> What is your proposal for the semantic?
>>> 
>>> (IIRC the dead flag is required for values that are never used and
the
>>> proposed fix somehow goes against that.)
>>> 
>>>> 
>>>> - Matthias
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> On Jun 28, 2017, at 2:28 AM, Björn Pettersson A <bjorn.a.pettersson at
ericsson.com> wrote:
> 
> Not sure if I could follow everything in this discussion regarding
subregisters. But I think the problem posted by Mikael just happened to involve
subregisters, and the discussions about subregisters is confusing when it comes
to Mikaels original question/problem.
> 
> I think that the bundle could look something like this just as well:
> 
>     BUNDLE %vreg1<def,dead>
>       * %vreg1<def> = add %vreg2, %vreg3
>       * call @foo, %vreg1<internal-use>
> 
> No subregisters involved.
> %vreg1 is dead after the bundle.
True
> %vreg1 is not dead when defined at the "add", because it is used
later in the same bundle.
CodeGen shouldn't and doesn't care. The order inside a bundle is
unspecified. There are a number of things that would make sense:
- The bundled instructions are executed in parallel and the call reads the value
of vreg1 before the add happened
- The bundled instructions are executed in sequence and the call reads the
definition from the add
- Both instructions are predicated and we don't even execute the call or the
add at all in each run

The gist is: The generic CodeGen code doesn't know how a bundle behaves
internally. As far as codegen is concerned executing the bundle is an atomic
operation so it feels alot like a single instruction with just all operands
merged together.

To make things confusing: A lot of the post-RA passes are not setup to traverse
the bundle and the instructions inside, they only ever look at the first
instruction. The way this is dealt with today is that we add the summary
operands on the first instruction of a bundle (typically BUNDLE or sometimes a
target specific opcode).
> 
> Should perhaps the %vreg1 not be included in the BUNDLE head at all here?
The vreg1 has to be in the header.
> (but shouldn't the BUNDLE head be a summary of what is going on inside
the bundle, so leaving out information about %vreg1 being defined seems wrong)
Yes
> 
> To me it seems wrong to add "dead" to the def of %vreg1 at the
add (considering the internal-use).
> Maybe that even answers the question that the "mismatch" between
dead-markings should be OK.
> Or would it be OK to mark %vreg1 as dead at the add, even though we have a
later internal-use?
I think the answer here is that targets shouldn't expect dead/kill to mean
something for the ordering inside the bundle. The flags are only about the
effects when viewing the whole bundle as a unit. Hence we also need the
internal-use flag, because normal instructions cannot read something that is
defined by the same instruction. But a BUNDLE can read data that is defined as
part of the same BUNDLE.

- Matthias