This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]