On Sun, Sep 20, 2009 at 01:49:39PM -0400, Andrew Hutchinson wrote:
All,
I have been debugging AVR port to see why we fail to match so many bit
test opportunities.
When dealing with longer modes I have come across a problem I can not solve.
Expansion in RTL for a bit test can produce two styles.
STYLE 1 Bit to be tested is NOT LSB (e.g. if ( longthing & 0x10)), the
expanded code contains the test as:
(and:SI (reg:SI 45 [ lx.1 ])
(const_int 16 [0x10]))
Bit tests are matched by combine. Combine has no problems with this and
eventually creates a matching pattern based on the conversion of the AND
to a zero extraction
(set (pc)
(if_then_else (ne (zero_extract:SI (subreg:QI (reg:SI 45 [ lx.1 ]) 0)
(const_int 1 [0x1])
(const_int 4 [0x4]))
(const_int 0 [0x0]))
(label_ref:HI 133)
(pc)))
This will match Bit test patterns and produces optimal code. :-)
Unfortunately, when combine knows about upper bits that are zero, it
will generate an lshiftrt instead, which can't be legitimately matched
by a bit test.
I have a patch for this which I haven't gotten around yet to test it
separately in trunk and formally submit to the patches list, but you can
extract it from arc-20081210-branch:
2008-12-02 J"orn Rennecke <joern.renne...@arc.com>
* combine.c (undo_since): New function, broken out of:
(undo_all).
(combine_simplify_bittest): New function.
(combine_simplify_rtx, simplify_if_then_else): Use it.
* config/arc/arc.c (arc_rtx_costs): Check for bbit test.
svn diff -r144651:144652
svn://gcc.gnu.org/svn/gcc/branches/arc-20081210-branch/gcc/combine.c
