[LLVMdev] MI bundle liveness attributes

[Andrew Trick]

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