[llvm-commits] CVS: llvm/lib/Target/ARM/ARMInstrInfo.cpp ARMInstrInfo.h ARMTargetMachine.cpp ARMTargetMachine.h

[Evan Cheng]

On May 16, 2007, at 11:42 AM, Chris Lattner wrote:

>>> Yes, I think this should be the distinction between M_PREDICATED  
>>> (the
>>> instr already has a predicate field, but may be set to 'always') vs
>>> M_PREDICABLE (the instr may or may not have a predicate field, but
>>> PredicateInstruction can change it into one that does).
>>
>> I dunno if that's the right solution. To me, whether something is
>> "predicated" is a dynamic property. It's dependent on the value of
>> its predicated field.
>
> Okay, lets put this another way.  You need to know whether you *can*
> predicate something, this is the isPredicable() property we were
> talking about.
>
> Why do you need to know if something is predicated?  What does that
> mean?
>
> Does that mean it can be predicated and the predicate is not set to
> always?  What client do you expect for this?

Right. The only potential client is the if-converter. If anything is  
already predicated on a non-always predicate before if-conversion, it  
needs to know.

You proposed having two separate properties. I think we have need  
one, i.e. whether something has a predicate field. Agreed?

>
>>> Another thing that occurred to me is that predicates have
>>> implications for livevar analysis (specifically, the scavenger).
>>> Consider this code:
>>>
>>> R3 = add [lt] ...
>>> R3 = sub [ge] ...
>>>
>>> Note that the add is not dead. :)
>>
>> Yeah, this is a problematic issue.
>
> yes.
>
>> For now, I think the if-converter
>> has to be a pre-emit pass. That means it will have to do some basic
>> CFG xform (i.e. remove dead blocks) unless we can move branch folding
>> past it. :-(
>
> Ick. :( :(

Indeed. But I don't see any other solution unless we want to teach  
the scavenger all about predication. That may come one day, but not now.

>>>> Come to think of it, perhaps we should not have selects if the
>>>> target
>>>> uses if-conversion.
>>>
>>> That would be very nice.  Alternatively, we could have the isel
>>> "know" about predicated moves and generate them?
>>
>> I think the right solution is to transform select's back to control
>> flow. However, this requires doing the ugly hack to do the lowering
>> at scheduling time, right?
>
> Yes.  The PPC and Sparc backend (in v8 mode) both do this.
>
> However, why not just emit the predicated instructions from the
> isel?  That would be much more efficient and clean, no?

I don't think so, we can't have isel / scheduler producing code that  
have multiple instructions targeting the same register. And I don't  
want to teach the if-converter about already predicated code. e.g.

extern void foo(int);
int t1(int a, int b) {
   int x = a ? b+1 : b-1;
   foo(x);
   return x;
}

i.e.

define i32 @t1(i32 %a, i32 %b) {
entry:
         %tmp2 = icmp eq i32 %a, 0               ; <i1> [#uses=1]
         %iftmp.0.0.v = select i1 %tmp2, i32 -1, i32 1           ;  
<i32> [#uses=1]
         %iftmp.0.0 = add i32 %iftmp.0.0.v, %b           ; <i32>  
[#uses=2]
         tail call void @foo( i32 %iftmp.0.0 )
         ret i32 %iftmp.0.0
}

We currently produce:

_t1:
         stmfd sp!, {r4, r7, lr}
         add r7, sp, #4
         mvn r3, #0
         mov r2, #1
         cmp r0, #0
         moveq r2, r3
         add r4, r2, r1
         mov r0, r4
         bl L_foo$stub
         mov r0, r4
         ldmfd sp!, {r4, r7, pc}

But what we really want is

_t1:
         stmfd sp!, {r4, r7, lr}
         add r7, sp, #4
         cmp r0, #0
         mvneq r2, #0            <== We can't produce this if we isel  
predicated code
         movne r2, #1            <==
         add r4, r2, r1
         mov r0, r4
         bl L_foo$stub
         mov r0, r4
         ldmfd sp!, {r4, r7, pc}

And then somehow turn this into:

_t1:
         stmfd sp!, {r4, r7, lr}
         add r7, sp, #4
         cmp r0, #0
         subeq r2, r1, #1
         addne r2, r1, #1
         mov r0, r4
         bl L_foo$stub
         mov r0, r4
         ldmfd sp!, {r4, r7, pc}

Evan

>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits