[llvm-dev] Ok with mismatch between dead-markings in BUNDLE and bundled instructions?

[Quentin Colombet via 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