On Mon, Oct 26, 2020 at 7:36 AM Jan Hubicka <hubi...@ucw.cz> wrote: > > > On Mon, Oct 26, 2020 at 7:23 AM Jan Hubicka <hubi...@ucw.cz> wrote: > > > > > > Hi, > > > this patch implements thre two-state optimize_for_size predicates, so > > > with -Os > > > and with profile feedback for never executed code it returns > > > OPTIMIZE_SIZE_MAX > > > while in cases we decide to optimize for size based on branch prediction > > > logic > > > it return OPTIMIZE_SIZE_BALLANCED. > > > > > > The idea is that for places where we guess that code is unlikely we do not > > > want to do extreme optimizations for size that leads to many fold > > > slowdowns > > > (using idiv rather than few shigts or using rep based inlined stringops). > > > > > > I will update RTL handling code to also support this with BB granuality > > > (which > > > we don't currently). We also should make attribute cold to lead to > > > OPTIMIZE_SIZE_MAX I would say. > > > > > > LLVM has -Os and -Oz levels where -Oz is our -Os and LLVM's -Os would > > > ocrrespond to OPTIMIZE_SIZE_BALLANCED. I wonder if we want to export > > > this to command line somehow? For me it would be definitly useful to > > > test things, I am not sure how "weaker" -Os is desired in practice. > > > > > > Bootstrapped/regtested x86_64-linux, I will commit it later today if > > > there are no comments. > > > > > > H.J., can you plase update your patch on stringopts? > > > > > > > Please ahead. My patches should be orthogonal to yours. > > For example you had patch that limited "rep cmpsb" expansion for > -minline-all-stringops. Now the conditions could be > -minline-all-stringops || optimize_insn_for_size () == OPTIMIZE_SIZE_MAX > since it is still useful size optimization. > > I am not sure if you had other changes of this nature? (It is bit hard > to grep compiler for things like this and I would like to get these > organized to optimize_size levels now).
Shouldn't it apply to all functions inlined by -minline-all-stringops? -- H.J.
