On Wed, Nov 21, 2018 at 3:16 PM Jeff Law <l...@redhat.com> wrote: > > On 11/21/18 7:13 AM, Richard Biener wrote: > > On Wed, Nov 21, 2018 at 1:12 AM Jeff Law <l...@redhat.com> wrote: > >> > >> On 11/20/18 6:42 AM, Michael Matz wrote: > >>> Hi, > >>> > >>> this bug report is about cris generating worse code since tree-ssa. The > >>> effect is also visible on x86-64. The symptom is that the work horse of > >>> adler32.c (from zlib) needs spills in the inner loop, while gcc 3 did not, > >>> and those spills go away with -fno-tree-reassoc. > >>> > >>> The underlying reason for the spills is register pressure, which could > >>> either be rectified by the pressure aware scheduling (which cris doesn't > >>> have), or by simply not generating high pressure code to begin with. In > >>> this case it's TER which ultimately causes the register pressure to > >>> increase, and there are many plans in people minds how to fix this (make > >>> TER regpressure aware, do some regpressure scheduling on gimple, or even > >>> more ambitious things), but this patch doesn't tackle this. Instead it > >>> makes reassoc not generate the situation which causes TER to run wild. > >>> > >>> TER increasing register pressure is a long standing problem and so it has > >>> some heuristics to avoid that. One wobbly heuristic is that it doesn't > >>> TER expressions together that have the same base variable as their LHSs. > >>> But reassoc generates only anonymous SSA names for its temporary > >>> subexpressions, so that TER heuristic doesn't apply. In this testcase > >>> it's even the case that reassoc doesn't really change much code (one > >>> addition moves from the end to the beginning of the inner loop), so that > >>> whole rewriting is even pointless. > >>> > >>> In any case, let's use copy_ssa_name instead of make_ssa_name, when we > >>> have an obvious LHS; that leads to TER making the same decisions with and > >>> without -fno-tree-reassoc, leading to the same register pressure and no > >>> spills. > > > > I don't think this is OK. Take one example, in rewrite_expr_tree for the > > final > > recursion case we replace > > > > a_1 = _2 + _3; > > > > with sth else, like > > > > _4 = _5 + 1; > > > > so we compute a new value that may not have been computed before and > > certainly not into the user variable a. If you change this to instead > > create > > > > a_4 = _5 + 1; > > > > then this leads to wrong debug info showing a value for 'a' that never > > existed. > > You can observe this with > But isn't the point to use an underlying SSA_NAME_VAR when we have one > that should be appropriate? Are we just being too aggressive with using > copy_ssa_name?
Well, sure - there _might_ be places that could use copy_ssa_name in reassoc but I doubt so. Usually code-generation should not use copy_ssa_name given the aforementioned issues. Richard. > > jeff >
