On Mon, Nov 09, 2015 at 03:51:32AM -0600, Segher Boessenkool wrote: > > >From the original patch submission, it looks that this patch would > > also benefit x86_32. > > Yes, that is what I thought too. > > > Regarding the above code size increase - do you perhaps have a > > testcase, to see what causes the difference? > > I could extract some. It happens quite rarely on usual code. > > > It isn't necessary due to > > the patch, but perhaps some loads are moved to the insn and aren't > > CSE'd anymore.
I don't have a small testcase yet. What causes the degradation is that sometimes we end up with imul reg,reg instead of imul mem,reg. In the normal case we already have imul mem,reg after expand, so the patch doesn't change anything in the normal case. Even if expand didn't do it fwprop would I think. It also isn't LRA that is doing it, the MEMs in case are not on stack. Maybe as you say some CSE pass. For x86_64, which has many more registers than i386, often a peephole fires that turns a mov reg,reg ; imul mem,reg into an mov mem,reg ; imul reg,reg which makes the generated machines code identical with or without the patch (tested on a Linux build, 12MB text). The i386 size regression is 0.01% btw (comparable to the gains for other targets). Segher
