[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