Why doesn't combine try matching "unsimplified" expressions when it fails?
This would at least permit creating patterns based on explicit format
of input RTL without the added vagaries of simplification
Andy
Joern Rennecke wrote:
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
