This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Is this wrong optimization in cse1 pass?
On Mon, Sep 13, 2010 at 10:15 PM, Ian Lance Taylor <iant@google.com> wrote:
> "Bingfeng Mei" <bmei@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