On Mon, Sep 13, 2010 at 10:15 PM, Ian Lance Taylor <i...@google.com> wrote: > "Bingfeng Mei" <b...@broadcom.com> writes: > >> I am experimenting some cond_exec patterns to better support >> predicate in our target. I came across the following optimization >> done in cse1, and not sure if it is correct behaviour or my fault. >> Basically, cse1 performs copy propagation for insn 12 and 16 based >> on assignment in insn 10. However, there is a conditional assignment >> of reg 86 in insn 11. Shouldn't GCC perform the optimization here? > > I don't think any of the current gcc ports expect to see a cond_exec > before the ifcvt pass, which is where define_cond_exec is implemented. > So, this sounds like a bug in combine which none of the current ports > trigger.
No no no! Geez, I thought someone with your experience in GCC would know better :-P State of things: having COND_EXEC before reload is finished is just plain wrong. No code before reload expects to see COND_EXECs. This is why most posts with support conditional execution have define_insn_and_splits with if_then_else before the split and cond_exec after reload (or, after pass_split_after_reload). Only post-reload if-conversion, i.e. pass_if_after_reload, will try to predicate streams of insns. Passes before reload, including combine, know nothing about COND_EXEC and do not understand the dataflow involved. The reasons for this are historical: ia64 not as relevant as projected, funding stopped, few targets where cond_exec really matters, spilling of predicate registers hard, and so on. Ciao! Steven
