[llvm-commits] CVS: llvm/lib/Target/ARM/ARMInstrInfo.cpp ARMInstrInfo.h ARMTargetMachine.cpp ARMTargetMachine.h
evan.cheng at apple.com
Wed May 16 11:21:59 PDT 2007
On May 16, 2007, at 10:09 AM, Chris Lattner wrote:
> On May 16, 2007, at 1:18 AM, Evan Cheng wrote:
>>> But even then I am not sure if that eliminate the need to have a
>>> virtual function isPredicatable. Conditional branches probably would
>>> require special handling. Also, while it isn't possible now, it's
>>> conceivable some instruction predicate field may not be 'always'
>>> coming into the if-conversion pass. In that case, it would require a
>>> target hook to examine the field anyway.
>> cmov is another class of M_PREDICATED ops that need to be dealt with
>> differently. We'll need a hook to check if something is already
>> predicated with non-always predicate.
> 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.
> 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. 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. :-(
>> 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?
> The isel does not know anything about moves at this point.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits