This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][3/n] Merge from match-and-simplify, first patterns and questions
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 17 Oct 2014 22:15:05 +0000
- Subject: Re: [PATCH][3/n] Merge from match-and-simplify, first patterns and questions
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1410151340120 dot 20733 at zhemvz dot fhfr dot qr>
On Wed, 15 Oct 2014, Richard Biener wrote:
> Caveat2: the GENERIC code-path of match-and-simplify does
> not handle everything fold-const.c does - for example
> it does nothing on operands with side-effects - foo () * 0
> is not simplified to (foo(), 0). It also does not
> get the benefit from "loose" type-matching by means of
> the STRIP_[SIGN_]NOPS fold-const.c performs on operands
> before doing its pattern matching. This means that
> when I remove stuff from fold-const.c there may be
> regressions that are not anticipated (in frontend code
> and for -O0 only - with optimization the pattern should
> apply on GIMPLE later).
>
> So - are we happy to lose some oddball cases of GENERIC
> folding? (hopefully oddball cases only...)
I don't see any problems with the side effects case; that seems much
better only handled on GIMPLE. It seems more plausible something could
depend on STRIP_[SIGN_]NOPS calls.
--
Joseph S. Myers
joseph@codesourcery.com