This is the mail archive of the gcc-patches@gcc.gnu.org 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][RFA][PR tree-optimization/79095] Improve overflow test optimization and avoid invalid warnings


On 01/27/2017 02:35 PM, Richard Biener wrote:
On January 27, 2017 7:30:07 PM GMT+01:00, Jeff Law <law@redhat.com> wrote:
On 01/27/2017 05:08 AM, Richard Biener wrote:
On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse <marc.glisse@inria.fr>
wrote:
On Thu, 26 Jan 2017, Jeff Law wrote:

I assume this causes a regression for code like

unsigned f(unsigned a){
  unsigned b=a+1;
  if(b<a)return 42;
  return b;
}

Yes.  The transformation ruins the conversion into ADD_OVERFLOW for
the +-
1 case.  However, ISTM that we could potentially recover the
ADD_OVERFLOW in
phi-opt.  It's a very simple pattern that would be presented to
phi-opt, so
it might not be terrible to recover -- which has the advantage that
if a
user wrote an optimized overflow test we'd be able to recover
ADD_OVERFLOW
for it.


phi-opt is a bit surprising at first glance because there can be
overflow
checking without condition/PHI, but if it is convenient to catch
many
cases...

Yeah, and it's still on my TODO to add some helpers exercising
match.pd COND_EXPR
patterns from PHI nodes and their controlling condition.
It turns out to be better to fix the existing machinery to detect
ADD_OVERFLOW in the transformed case than to add new detection to
phi-opt.

The problem with improving the detection of ADD_OVERFLOW is that the
transformed test may allow the ADD/SUB to be sunk.  So by the time we
run the pass to detect ADD_OVERFLOW, the test and arithmetic may be in
different blocks -- ugh.

The more I keep thinking about this the more I wonder if transforming
the conditional is just more of a headache than its worth -- the main
need here is to drive propagation of known constants into the THEN/ELSE

clauses.  Transforming the conditional makes that easy for VRP & DOM to

discover those constant and the transform is easy to write in match.pd.

But we could just go back to discovering the case in VRP or DOM via
open-coding detection, then propagating the known constants without
transforming the conditional.

Indeed we can do that.  And in fact with named patterns in match.pd you could even avoid the open-coding.
?!? Is there an example of this somewhere?

jeff


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