This is the mail archive of the
mailing list for the GCC project.
Re: ifcvt limitations?
- From: Jeff Law <law at redhat dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 02 Jun 2015 10:50:36 -0600
- Subject: Re: ifcvt limitations?
- Authentication-results: sourceware.org; auth=none
- References: <556DD277 dot 1070501 at foss dot arm dot com>
On 06/02/2015 09:57 AM, Kyrill Tkachov wrote:
It's just never been implemented or tested per this comment in
I'm stuck on noce_process_if_block (in ifcvt.c) and what I think is a
restriction that the THEN-block contents have to be only a single set
insn. This fails on aarch64 because we get an extra zero_extend.
In particular, the following check in noce_process_if_block triggers:
insn_a = first_active_insn (then_bb);
if (! insn_a
|| insn_a != last_active_insn (then_bb, FALSE)
|| (set_a = single_set (insn_a)) == NULL_RTX)
Is there any particular reason why the code shouldn't be able to handle
arbitrarily large contents
in then_bb (within a sane limit)?
/* We're looking for patterns of the form
(1) if (...) x = a; else x = b;
(2) x = b; if (...) x = a;
(3) if (...) x = a; // as if with an initial x = x.
The later patterns require jumps to be more expensive.
??? For future expansion, look for multiple X in such patterns. */
I think folks would look favorably upon removing that limitation,
obviously with some kind of cost checking.