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: [tcb] Fix PR 18178


Diego Novillo wrote:
> 
> This patch addresses some of the FIXME notes in the VRP pass.  The main 
> change is the inclusion of scalar evolution information in range 
> propagation to derive narrower ranges.  This allows us to remove the 
> bound checking code in PR 18178.
> 
> I needed to jump through a few hoops to get scalar evolution 
> information.  It is currently a bit too intertwined with loop 
> optimization passes, which is understandable.  But I would like to have 
> a point of entry to the analyzer that didn't force us to do all the 
> initialization in each pass (see the code that was added to 
> execute_vrp).  Sebastian, is that feasible?
> 

The problem is that scev caches its information in a database under
the form: SSA_NAME -> evolution.  Because the database can contain
evolutions with symbols, a part of the information should be discarded
when an optimizer deletes SSA_NAMEs.  Zdenek thinks that it is too
costly to flush out only a part of the information because you have to
walk over all the elements in the database.  A solution would be to
split the scev cache into fully instantiated and symbolic evolutions,
and invalidate only the symbolic part.

> +  /* FIXME.  When dealing with unsigned types,
> +     analyze_scalar_evolution sets STEP to very large unsigned values
> +     when the evolution goes backwards.  This confuses this analysis
> +     because we think that INIT is the smallest value that the range
> +     can take, instead of the largest.  Ignore these chrecs for now.  */
> +  if (INTEGRAL_TYPE_P (TREE_TYPE (step)) && TYPE_UNSIGNED (TREE_TYPE (step)))
> +    return;
> +
> +  /* If STEP is negative, then INIT is the maximum value the range
> +     will take.  Otherwise, INIT is the minimum value.  */
> +  init_is_max = (tree_int_cst_sgn (step) < 0);
> +

fold could help fixing this problem.  Try something like:
init_is_max = (tree_int_cst_compare (base, fold (PLUS_EXPR, base, step)) == 1)


Sebastian


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