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

[Chris Lattner]

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

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

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

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

    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