[Patch, i386] Avoid LCP stalls (issue5975045)

Jan Hubicka hubicka@ucw.cz
Fri Mar 30 20:37:00 GMT 2012

> Hi Richard, Jan and H.J.,
> Thanks for all the quick responses and suggestions.
> I had tested my patch when tuning for an arch without the LCP stalls,
> but it didn't hit an issue in reload because it didn't require
> rematerialization. Thanks for pointing out this issue.
> Regarding the penalty, it can be >=6 cycles for core2/corei7 so I

6 cycles is indeed quite serve and may pay for extra spill. I guess
easiest way is to benchmark peephole variant and see what comes first.
You may be able to see the differences better in 32bit mode due to
register pressure issues.

> thought it would be best to force the splitting even when that would
> force the use of a new register, but it is possible that the peephole2
> approach will work just fine in the majority of the cases. Thanks for
> the peephole2 patch, H.J., I will test that solution out for the case
> I was trying to solve.
> Regarding the penalty on AMD, reading Agner's guide suggested that
> this could be a problem on Bulldozer, but only if there are >3
> prefixes, and I'm not sure how often that will occur for this type of

I can not think of case where MOV instruction in question would have 3
prefixes. It can have size overload and REX prefix, but REX usually do not
count.  You may try to benchmark Buldozer, but I would be surprised if there
was any benefits.

We need to run some benchmarks for generic/generic32 models on AMD machine
anyway.  I would guess that this transformation should be safe. Cost of extra
register move is not high compared to the 16bit store overhead.


More information about the Gcc-patches mailing list