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).
