[LLVMdev] MI bundle liveness attributes

Andrew Trick atrick at apple.com
Thu Aug 9 17:08:50 PDT 2012


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



More information about the llvm-dev mailing list