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

> 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 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.

- Matthias

> 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

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