This is the mail archive of the 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][3/n] Merge from match-and-simplify, first patterns and questions

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

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