>> 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? >> 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. :( :( >>> 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? -Chris _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
