https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66119
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to James Greenhalgh from comment #7) > (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). So maybe instead compute that "default" in SRA itself?
