[patch] for PR28411

Roger Sayle roger@eyesopen.com
Mon Aug 21 16:12:00 GMT 2006


Hi Zdenek,

On Fri, 4 Aug 2006, Zdenek Dvorak wrote:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00090.html
> here is the updated version...
>
> 	PR tree-optimization/28411
> 	* double-int.c (double_int_div): Use double_int_divmod.
> 	(double_int_divmod, double_int_sdivmod, double_int_udivmod,
> 	double_int_mod, double_int_smod, double_int_umod): New functions.
> 	* double-int.h (double_int_divmod, double_int_sdivmod,
> 	double_int_udivmod, double_int_mod, double_int_smod, double_int_umod):
> 	Declare.
> 	* tree-ssa-loop-ivopts.c (constant_multiple_of): Returns the result
> 	in double_int.
> 	(get_computation_aff, get_computation_cost_at): Handle double_int
> 	return type of constant_multiple_of.

Sorry for the delay, I'm just back from vacation.

This is OK for mainline, and for 4.1 after a few days on mainline without
problems.



> I still do not understand why you consider it better that way, though.

It's better to define interfaces that may be implemented efficiently,
even though they share generic infrastructure initially, than to
introduce poor interfaces that are difficult to optimize/improve later.
I suspect the benefit of these cleaner interfaces won't be apparent
until their implementations are refined/specialized later.

For example, your new double_int_umod can take advantage of tricks such
as:

  if (a.high == 0 && b.high == 0)
    return uhwi_to_double_int (a.low % b.low);

This takes advantage of the host's integer arithmetic instructions and
is therefore far more efficient than fold-const.c's div_and_round_double.
For testing whether array strides are multiples of 4 or 8, a not uncommon
usage, this should help compile-time.  The current design of some of the
middle-end's double width aritmetic interfaces is a little clumsy and
make this sort of optimization tricky.


One of the possible motives behind GCC's mysterious TYPE_IS_SIZETYPE
semantics, where the middle-end processes integers whose values lie
outside their type's TYPE_MINVAL/TYPE_MAXVAL bounds may have been caused
by GCC's inability to detect compile-time overflow of unsigned
multiplications (using the current APIs).  Hence, for stor-layout to
determine if an object is too large,  we always sign-extend these
unsigned types!?  Just one example of a poor middle-end API inadvertantly
leading to tree-ssa chaos.


Whilst I agree with your experience from working with tree-level loop
optimizations, that the previous middle-end interfaces are problematic,
we need to learn from those mistakes lest we end up with a duplicate
API that inherits many of the original's defficiencies.  Hopefully, we
can correct more than just the blight of TREE_OVERFLOW.


Thanks again for fixing this.

Roger
--



More information about the Gcc-patches mailing list