This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR target/28946
- From: Roger Sayle <roger at eyesopen dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 5 Sep 2006 07:20:02 -0600 (MDT)
- Subject: Re: [PATCH] Fix PR target/28946
On Tue, 5 Sep 2006, Uros Bizjak wrote:
> 2006-09-06 Uros Bizjak <uros@kss-loka.si>
>
> PR target/28946
> * combine.c (try_combine): Force PARALLEL of comparison and
> arithmetic insn even if arithmetic result is not used.
>
> * gcc.target/i386/pr28946.c: New test.
I was going to point out tht a generic change to combine like this
really needs more testing that C & C++ on x86, especially during
stage 3. However, from your latest comments in the bugzilla PR it
looks like you've already discovered as issue with the use of "and"
vs "test".
Taking a small step backwards perhaps we're missing a completely
different optimization here... if (((unsigned)x >> 5) != 0) could
probably be better expanded/transformed as if ((unsigned) x >= 32),
especially on pentium-4s where the cost of a shift is significant.
A less intrusive patch/workaround for the 4.0 and 4.1 branches might
be to add a peephole2 to recognize the "shrl $foo, reg; testl reg, reg"
sequence and simplify it. Less than ideal, but unlikely to change
anything other than the affected code.
However if we stick with a combine solution, this might be one of
those instances where we need to attempt to recognize the combination
directly (to catch testl or a mythical shift-compare, ARM?), and if
that fails, try again with a parallel containing the original SET.
Roger
--