https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #36 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 22 May 2018, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 > > bin cheng <amker at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |amker at gcc dot gnu.org > > --- Comment #35 from bin cheng <amker at gcc dot gnu.org> --- > (In reply to prathamesh3492 from comment #33) > > Created attachment 42341 [details] > > Test-case to reproduce regression with cortex-m7 > > > > I have attached an artificial test-case that is fairly representative of the > > regression we are seeing in a benchmark. The test-case mimics a > > deterministic finite automaton. With code-hoisting there's an additional > > spill of r5 near beginning of the function. > > > ... > > > > Without code-hoisting it is reusing r3 to store a + 1, while due to code > > hoisting it uses the extra register 'r2' to store the value of hoisted > > expression a + 1. > > > > Would it be a good idea to somehow "limit" the distance (in terms of number > > of basic blocks maybe?) between the definition of hoisted variable and it's > > furthest use during PRE ? If that exceeds a certain threshold then PRE > > should choose not to hoist that expression. The threshold could be a param > > that can be set by backends. > > Does this analysis look reasonable ? > > It might be more accurate to calculate register pressure and use that to guide > code hoisting. I introduced register pressure hoisting for RTL under option > -fira-hoist-pressure, basically similar thing needs to be done here. > > The proposed Tree-SSA register pressure patch set is still under review, but > please note it only does minimal now by only computing register pressure. To > make it useful in this case, it may need to be improved by > calculating/recording live range for statements (I did that in previous > version > patch). We would also need interfaces updating live range information in line > with code motion. One important thing on GIMPLE is that stmt order (inside a BB at least) is quite arbitrary and thus LIVE should consider the stmts ordered in LIVE-optimal way to not introduce too much noise. It might be that we should only consider live-through [loops] for heuristics in some places plus the obvious changes in liveness that transforms induce.
