Hi Sergei,
It seems to me that you can represent the semantics of a conditional
instruction by adding a use of the conditionally defined register to the
instruction.
The value of the output register of an instruction is either the value
of the instruction if it was conditionally executed or the value of the
output register before the instruction.
The Bundle would be:
BUNDLE %PC<imp-def>, %R0<imp-def>, %P0<imp-use,kill>,
%R16<imp-use>,
%R0<imp-use,kill>
* %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0,
%R0<imp-use,kill>
* %P0<def> = CMPEQri %R16, 0
The individual instruction would be:
%R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0,
%R0<imp-use,
kill>;
How would you use cond-def/uses? How would they change liveness?
Best,
Arnold
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.
On 8/9/2012 11:48 AM, Sergei Larin wrote:>
> Hello everyone,
>
> Let me (re)present a question that might have previously been discussed,
> but did not result in any code (AFIK).
>
> How do we represent a _conditional_ assignment (def) in a bundle MI?
>
> More contents - currently we expose internal def/use/kill information to
a
> bundle header - something like this:
>
>
> BUNDLE %PC<imp-def>, %R0<imp-def>, %P0<imp-use,kill>,
%R16<imp-use>
> * %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0;
> * %P0<def> = CMPEQri %R16, 0;
>
> Here CMPEQri is a compare to a predicate register instruction, and
> LDriuh_cdnNotPt is a _conditional_ load, which might or might not
> Take place based on the outcome of the compare... As such R0 might or might
> not be defined in this bundle, which obviously changes the liveness update
> process.
>
> My question, do we need another attribute along with isImplicit and
> isEarlyClobber etc. to designate a conditional def? Furthermore, depending
> on architectural details we well might have a conditional use as well...
and
> what about the individual (unbundled) def/use? Should this:
>
> %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0;
>
> ...become this:
>
> %R0<def-cond> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0;
>
> or even:
>
> %R0<def-cond> = LDriuh_cdnNotPt %P0<kill,internal>,
%R16<use-cond>, 0;
>
> So, if I am missing something in current implementation or an ongoing
> discussions (and that is entirely possible since I am just back after
> vacation), please let me know how to achieve this functionality, but if
this
> is something missing in implementation, let's discuss how do we want to
> realize it.
>
> Thanks.
>
> Sergei Larin
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.
Arnold, Interesting point. This fake use would also need to be probably marked as isUndef(), but I could not foresee all possible corner cases from that. Could it be overly conservative? Would I lose the ability of some sort "predicate value propagation" that I seem to gain from introduction of an explicit flag? Can someone comment? Thanks. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.> -----Original Message----- > From: Arnold Schwaighofer [mailto:arnolds at codeaurora.org] > Sent: Thursday, August 09, 2012 1:54 PM > To: Sergei Larin > Cc: 'LLVM Developers Mailing List' > Subject: Re: [LLVMdev] MI bundle liveness attributes > > Hi Sergei, > > It seems to me that you can represent the semantics of a conditional > instruction by adding a use of the conditionally defined register to > the instruction. > > The value of the output register of an instruction is either the value > of the instruction if it was conditionally executed or the value of the > output register before the instruction. > > The Bundle would be: > > BUNDLE %PC<imp-def>, %R0<imp-def>, %P0<imp-use,kill>, %R16<imp-use>, > %R0<imp-use,kill> > * %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0, > %R0<imp-use,kill> > * %P0<def> = CMPEQri %R16, 0 > > The individual instruction would be: > > %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0, %R0<imp-use, > kill>; > > How would you use cond-def/uses? How would they change liveness? > > Best, > Arnold > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > > On 8/9/2012 11:48 AM, Sergei Larin wrote: > > > > Hello everyone, > > > > Let me (re)present a question that might have previously been > > discussed, but did not result in any code (AFIK). > > > > How do we represent a _conditional_ assignment (def) in a bundle > MI? > > > > More contents - currently we expose internal def/use/kill > > information to a bundle header - something like this: > > > > > > BUNDLE %PC<imp-def>, %R0<imp-def>, %P0<imp-use,kill>, %R16<imp-use> > > * %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0; > > * %P0<def> = CMPEQri %R16, 0; > > > > Here CMPEQri is a compare to a predicate register instruction, and > > LDriuh_cdnNotPt is a _conditional_ load, which might or might not > Take > > place based on the outcome of the compare... As such R0 might or > might > > not be defined in this bundle, which obviously changes the liveness > > update process. > > > > My question, do we need another attribute along with isImplicit > and > > isEarlyClobber etc. to designate a conditional def? Furthermore, > > depending on architectural details we well might have a conditional > > use as well... and what about the individual (unbundled) def/use? > Should this: > > > > %R0<def> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0; > > > > ...become this: > > > > %R0<def-cond> = LDriuh_cdnNotPt %P0<kill,internal>, %R16, 0; > > > > or even: > > > > %R0<def-cond> = LDriuh_cdnNotPt %P0<kill,internal>, %R16<use-cond>, > 0; > > > > So, if I am missing something in current implementation or an > > ongoing discussions (and that is entirely possible since I am just > > back after vacation), please let me know how to achieve this > > functionality, but if this is something missing in implementation, > > let's discuss how do we want to realize it. > > > > Thanks. > > > > Sergei Larin > > > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.
On 8/9/2012 2:25 PM, Sergei Larin wrote:> > Interesting point. This fake use would also need to be probably marked as > isUndef(), but I could not foresee all possible corner cases from that.It's not undef, it's exactly %R0. If the condition fails, R0 keeps its value.> Could it be overly conservative? Would I lose the ability of some sort > "predicate value propagation" that I seem to gain from introduction of an > explicit flag? Can someone comment?The predicate is the register P0, possibly with a negation. As long as P0 doesn't change between two instructions, you know that the predicate hasn't changed. The existing infrastructure doesn't force us to lose this information, so I believe that adding the cond-use flag is unnecessary. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation