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] for second problem in PR 18431


Hello,

> 
> On Sat, 13 Nov 2004, Zdenek Dvorak wrote:
> >
> > 	PR tree-optimization/18431
> > 	* fold-const.c (associate_trees): Do not produce x + 0.
> > 	(fold_widened_comparison, fold_sign_changed_comparison): New functions.
> > 	(fold): Use them.
> > 	* tree-ssa-loop-niter.c (upper_bound_in_type, lower_bound_in_type):
> > 	Export.
> > 	* tree.h (upper_bound_in_type, lower_bound_in_type): Declare.
> >
> 
> In addition to Joseph's request for at least one test case for new
> constant folding transformations, this mostly looks good with the
> following exception:
> 
> > +   arg1 = fold_convert (inner_type, arg1);
> > +   TREE_OVERFLOW (arg1) = ovflw;
> > +   if (TREE_CODE (arg1) == INTEGER_CST)
> > +     TREE_CONSTANT_OVERFLOW (arg1) = cst_ovflw;
> 
> You'll need to call copy_node if you intend to destructively modify
> the tree returned from fold_convert, which may be shared.

I guess I should check whether arg1 is an integer constant; i.e. the
code then should be

if (TREE_CODE (arg1) == INTEGER_CST)
  {
    TREE_OVERFLOW (arg1) = ovflw;
    TREE_CONSTANT_OVERFLOW (arg1) = cst_ovflw;
  }

There should be no problem with clearing the flags as it is done
here, since overflowed constants are not shared (see similar code
around c-typeck.c:3272).  I will add a comment (*).

> However,
> I'm a bit confused about why you have to do anything about TREE_OVERFLOW
> or TREE_CONSTANT_OVERFLOW here.  Shouldn't your patch work fine without
> it?  The call to fold_convert will either extend your integer constant
> or strip a useless NOP_EXPR, both of which handle TREE_OVERFLOW already.

In case it is converting integer constants, it may set overflow flag
(converting too large unsigned to signed does it; maybe there are also
other cases), which I cannot allow, since the rest of the transformation
would not work if the -1 produced here would be overflowed.

Zdenek

(*) Or perhaps it might be cleaner to add flag to fold_convert saying
    whether we want it to set overflow flags?


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