https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826
--- Comment #11 from Kishan Parmar <kishan at gcc dot gnu.org> ---
I agree that improving simplify-rtx is the better direction, and that was the
intent of this change, "simplify_shift_const_1 patch"
Starting from:
239 (set (reg:DI 130)
240 (plus:DI (and:DI (ashift:DI (lshiftrt:DI (subreg:DI (reg:SI 125 [ var
]) 0)
241 (const_int 6 [0x6]))
242 (const_int 2 [0x2]))
243 (const_int 20 [0x14]))
244 (const_int 800 [0x320])))
I was able to simplify it to:
239 (set (reg:DI 130)
240 (plus:DI (and:DI (lshiftrt:DI (subreg:DI (reg:SI 125 [ var ]) 0)
241 (const_int 4 [0x4]))
242 (const_int 20 [0x14]))
243 (const_int 800 [0x320])))
So the expression is indeed canonicalized to a simpler form. However, it still
fails to match any backend pattern.
At this point, combine reports below as well:
Failed to match:
(set (reg:DI 129)
(and:DI
(lshiftrt:DI (subreg:DI (reg:SI 125 [var]) 0)
(const_int 4))
(const_int 20))
Currently, combine only attempts splitting when three insns are combined and
the result can be split into two. In this case we combined four insns,
simplified to a 3-operation form, but since it does not match, no further split
is attempted.
My thought is: if we have already simplified the expression to a cleaner
3-operation form and it still does not match, should combine attempt to split
it further (e.g. separate the LSHIFTRT and AND) via find_split_point, even in
the 4→3 case?
In other words, rather than immediately falling back, should combine try
splitting the simplified form when matching fails, instead of requiring a
define_insn_and_split?
