On Tue, Jan 28, 2020 at 10:42:16AM +0100, Richard Biener wrote: > On Mon, Jan 27, 2020 at 10:47 PM Segher Boessenkool > <seg...@kernel.crashing.org> wrote: > > On Tue, Jan 21, 2020 at 02:10:21PM +0000, Wilco Dijkstra wrote: > > > While code hoisting generally improves codesize, it can affect performance > > > negatively. Benchmarking shows it doesn't help SPEC and negatively affects > > > embedded benchmarks. Since the impact is relatively small with -O2 and > > > mainly > > > affects -O3, the simplest option is to disable code hoisting for -O3 and > > > higher. > > > > Should this be a generic thing, not target-specific? > > The change doesn't make sense - I'm sure if you'd look at the actual cases > it's not code hoisting in itself but "optimizations" enabled by it that cause > the issues. It's probably the same thing as PRE causing issues downstream > for some benchmarks but do you disable PRE then by default just because of > that?
Well, that depends on how bad it is. And of course not if it is just because of benchmark peculiarities, we're not a banchmark compiler after all, we're meant to compile real code. But if PRE (just to continue your example) would mess that up more often than not, then yes, it should not be enabled by default. Segher
