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] Constant fold -A - B as -B - A (take 2)


> 
> Hi Jan,
> > At tree level we definitly need to preserve the fact that certain types
> > do not overflow and do not introduce overflows when they are not
> > supposed to happen.  This is important for loop optimization and other
> > friends.
> 
> Please don't confuse the issue.  The current loop optimizations operate
> at the RTL-level and should be independent of signedness issues and/or
> overflow.  The fact that this isn't the case, is due to real bugs in the
> code.

Yes, I had (nonexisting, at the present) loop optimization done on the
AST level in the mind.  Your patch I seen (to fold-const) does the
simplification too early.  I would not object if this is done at RTL
level.
> 
> Take for example, PR optimization/7799.  This failure is not because of
> the undefined behaviour of overflow, and many more competant compilers
> can perform this induction variable substitution.  The thing that they
> have to remember is that the termination condition *must* be changed
> from less than, to inequality and restricted to loops with known
> bounds.  With this fix we can enable many more loop optimizations in
> the presence of overflows.

In general when doing loop transformation, the possible overflows of
induction variables are very anoying.  I believe that we should do all
such transformations at AST level and use both information - hints from
frontends about the behaviour on overflow and hints from loop analysis
about known bounds.  

The loops with known bounds are not that common in real code, so first
one is important.  In order to do that, we must maintain tree level
optimizer safe and not introduce overflows even if it will probably
(maybe) work with current code (I am not certain about that as I believe
some parts of code generation already assume the absence of overflow).

Honza


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