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

[Evan Cheng]

On May 16, 2007, at 1:50 PM, Chris Lattner wrote:

>>> 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.
>
> Random thought, please don't run ifcvt when -fast is enabled.
>
>
>> You proposed having two separate properties. I think we have need
>> one, i.e. whether something has a predicate field. Agreed?
>
> I think there are really two separate things here.
>
> 1. Can we predicate this instruction.  If this bit is set, the if cvt
> pass can call "PredicateInstruction".  I'd actually propose that we
> let PredicateInstruction return failure as well, if it can't
> predicate the instruction for some reason.
>
> 2. Does this instruction have a non-always predicate (i.e. is it
> conditionally executed).
>
> The second predicate could be used by livevars and the scavenger: if
> an instruction has a predicate, all defs should become read/modify/
> write operations (or partial defs, or however you want to think about
> it).

These are two separate properties, yes. But only the former should be  
specified on the TargetInstrDescriptor. The later is a dynamic  
property and doesn't belong there.

If we are doing ifcvt before reg allocation, livevars had better be  
smarter than just treating predicated instructions as read/mod/write.  
That's going to artificially lengthen a lot of live intervals. But  
that's a worry for another day. This scheme may work well enough for  
the scavenger though.

>
>>>> 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.
>
> Yes, that is fine.  Long term,  the scavenger should do the right
> thing.  ideally we'd like to be able to ifcvt before RA.  We *really*
> want to ifcvt before block layout / constant islands.

Let's talk short term. Is it possible to move branch folding and  
debug label folding passes to post-ifcvt? I don't see why not?

>
>>> 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.
>
> Right now the isel and sched work fine.  The cmovs are marked as two-
> address instrs that r/m/w their operand and everything is fine.
>
>> And I don't
>> want to teach the if-converter about already predicated code.
>
> There are short-term vs long-term issues here.  In the short term, I
> think is important that the ifcvt pass handle already predicated
> code, even if it is just very conservatively.  Given that, we're
> talking about performance, not correctness.  Agree?

For now selects are not predicable. The post register allocation  
ifcvg is not capable of dealing with them. It will know how to deal  
with already predicated code, but on the whole BB granularity only.

>
>> We currently produce:
>>
>>          mvn r3, #0
>>          cmp r0, #0
>>          mov r2, #1
>>          moveq r2, r3
>>
>> But what we really want is
>>
>>          cmp r0, #0
>>          mvneq r2, #0
>>          movne r2, #1
>
> Given the input above, this seems like something the ifcvt pass could
> do on its own, before RA.  All it needs to know is that the mvn is
> predicable and that 'moveq' is mov, and that moveq is predicated.
> Turning the former into the later is just a copy propagation issue  
> then.
>
> The trick is that this has to be done before RA, because before RA
> the input code looks like:

Yeah, before RA.

Evan

>
>     vr1 = mvn #0
>     cmp ...
>     vr2 = mov #1
>     vr3 = moveq vr1, vr2
>
> This is trivial to ifcvt into:
>
>     vr1 = mvn #0
>     cmp ...
>     vr3 = moveq vr1, #1
>
> which is the code you want.
>
>
>
>> 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}
>
> This is a separate issue, which needs to be addressed at isel time.
>
> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits