Hi Sergei. If an instruction conditionally writes R0 then I think it needs to implicitly use R0 for proper liveness Andy On Aug 9, 2012, at 9:48 AM, Sergei Larin <slarin at codeaurora.org> 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. > >
Andy, Yes, this is what Arnold has suggested also, and from this point it looks like it should work, but it will require parsing the bundle every time we care to know whether this is a real use or a conditional def. This might become awkward... but I guess I should provide a better use case to prove my point. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.> -----Original Message----- > From: Andrew Trick [mailto:atrick at apple.com] > Sent: Thursday, August 09, 2012 7:09 PM > To: Sergei Larin > Cc: LLVM Developers Mailing List; Jakob Stoklund Olesen > Subject: Re: MI bundle liveness attributes > > Hi Sergei. If an instruction conditionally writes R0 then I think it > needs to implicitly use R0 for proper liveness > > Andy > > On Aug 9, 2012, at 9:48 AM, Sergei Larin <slarin at codeaurora.org> 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. > > > >
On Aug 13, 2012, at 8:34 AM, Sergei Larin <slarin at codeaurora.org> wrote:> Andy, > > Yes, this is what Arnold has suggested also, and from this point it looks > like it should work, but it will require parsing the bundle every time we > care to know whether this is a real use or a conditional def. This might > become awkward... but I guess I should provide a better use case to prove my > point.Sergei, the MachineInstr properties are exposed at the bundle level, we just don't seem to have the property that you need yet. Jakob: would it be generally useful to define either an MC instr or operand flag that indicates a conditionally written register? -Andy>> -----Original Message----- >> From: Andrew Trick [mailto:atrick at apple.com] >> Sent: Thursday, August 09, 2012 7:09 PM >> To: Sergei Larin >> Cc: LLVM Developers Mailing List; Jakob Stoklund Olesen >> Subject: Re: MI bundle liveness attributes >> >> Hi Sergei. If an instruction conditionally writes R0 then I think it >> needs to implicitly use R0 for proper liveness >> >> Andy >> >> On Aug 9, 2012, at 9:48 AM, Sergei Larin <slarin at codeaurora.org> 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. >>> >>> >