I've CC'd Ilya as he's been looking at related issues in the x86
backend, but from the other direction and I think he ought to be aware
of the interactions of this potential change and his work. In
particular depending on the costing in the x86 backend we may see fewer
propagations of GOTOFF constants to their use sites.
On 05/13/2015 11:46 PM, Kugan wrote:
ping?
Thanks,
Kugan
On 15/04/15 17:53, Kugan wrote:
As mentioned in PR65768, ARM gcc generates suboptimal code for constant
Uses in loop. Part of the reason is cprop is undoing what loop invariant
code motion did.
Zhenqiang posted a patch at to fix this based on rtx costs:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01321.html
I cleaned it up and bootstrapped, regression tested on x86_64-linux-gnu;
no new regressions. Is this OK for trunk?
Thanks,
Kugan
gcc/ChangeLog:
2015-04-15 Kugan Vivekanandarajah <kug...@linaro.org>
Zhenqiang Chen <zhenqiang.c...@linaro.org>
PR target/65768
* cprop.c (try_replace_reg): Check cost of constants before propagating.
So, I've reviewed the discussion from last year. To summarize my
understanding (please correct me if I'm wrong):
For various reasons we can have out-of-range constants for arithmetic,
logical or other operations. Those out-of-range constants will
typically be loaded into a register so that we can create valid insns.
LICM (and code motion in general) may hoist the constant register loads
out of loops, which we generally consider a win (there's certainly cases
where it is not though). It's particularly helpful when the constant
can be used by many instructions.
Global constant propagation may then try to replace uses of the constant
by the constant itself. Some of those propagations create valid insns,
but insns with a higher cost than their prior form. This is effectively
undoing LICM.
The patch changes the constant propagator to check the rtx cost of the
original form vs the propagated form and only propagates if the cost is
the same or lower -- the obvious idea being to propagate the constant
only when it saves us cycles.
Please correct me if I've got the overall summary incorrect.
There were several small issues raised that are probably worth a bit of
further discussion.
Register pressure. This patch can increase register pressure. It
happens if, prior to this patch the constant was propagated to all the
use sites. In that case the pseudo holding the constant is dead and
gets eliminated. With this patch we may decline to propagate the
constant to the use site (due to cost) and as a result the pseudo
remains live, thus increasing register pressure.
Based on Kugan's data, I don't see that as a major problem in practice.
Though Ilya might have specific cases for i686 PIC where it's a bigger
concern.
Performance. There wasn't a big win with this patch on either tested
architecture -- which is no great surprise. We're talking about very
small cost differences, possibly differences that can be well hidden by
modern pipelines.
General conerns about using rtx costing. What Kugan is doing here is
very similar to what's being done in other rtl passes WRT checking costs
before making transformations. So I don't see that as a significant
reason to object to the patch.
WRT the patch itself.
The "const_p" variable is poorly named, though I can kindof see how you
settled on it. Maybe "check_rtx_costs" or something along those lines
would be better.
The comment for the second hunk would probably be better as:
/* If TO is a constant, check the cost of the set after propagation
to the cost of the set before the propagation. If the cost is
higher, then do not replace FROM with TO. */
You should try to produce a testcase where this change shows a code
generation improvement. Given we're checking target costs, that test
will naturally be target specific. But please do try.
So with the two nits fixed and a testcase, I think this can go forward.
jeff
