[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

["jgreenhalgh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119

--- Comment #7 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> DEFPARAM (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED,
>           "sra-max-scalarization-size-Ospeed",
>           "Maximum size, in storage units, 
> 
> storage units!  But the value seems to be in bits?  It gets used as
> 
>             if (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (var)))
>                 <= max_scalarization_size)
> 

Well, that part should have been covered by:

+  unsigned max_scalarization_size
+    = (optimize_function_for_size_p (cfun)
+       ? PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SIZE)
+       : PARAM_VALUE (PARAM_SRA_MAX_SCALARIZATION_SIZE_SPEED))
+      * BITS_PER_UNIT;

>From the original patch, 

> Looks like get_move_ratio returns different things at SRA time (if I re-call
> it)
> and the time it gets invoked in toplev.c.

But, yes these parameters will cause a difference in code generation if
previously MOVE_RATIO could return different values at different times, as it
might well have if target_option_override set up a structure used by
MOVE_RATIO.

The patch I applied carries the hidden assumption that MOVE_RATIO is constant.
Clearly there are a number of situations we might not want that to be true
(say, for switchable targets - which I don't think your patch will help).