This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC: Patch 0/6] Rewrite the noce-ifcvt cost models
- From: Jeff Law <law at redhat dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>, gcc-patches at gcc dot gnu dot org
- Cc: nd at arm dot com, ramana dot radhakrishnan at arm dot com, bernds_cb1 at t-online dot de, ebotcazou at libertysurf dot fr, steven at gcc dot gnu dot org
- Date: Thu, 9 Jun 2016 10:58:52 -0600
- Subject: Re: [RFC: Patch 0/6] Rewrite the noce-ifcvt cost models
- Authentication-results: sourceware.org; auth=none
- References: <5617A4DE dot 6020004 at redhat dot com> <1464886438-17892-1-git-send-email-james dot greenhalgh at arm dot com>
On 06/02/2016 10:53 AM, James Greenhalgh wrote:
Hi,
When I was working in the area last year, I promised to revisit the cost
model for noce if-conversion and see if I could improve the modeling. This
turned out to be more tricky than I expected.
This patch set rewrites the cost model for noce if-conversion. The goal is
to rationalise the units used in the calculations away from BRANCH_COST,
which is only defined relative to itself.
Right. I think we all agreed that the key weakness of BRANCH_COST was
that its meaning is only defined relative to itself.
What we want is a costing metric that would allow us to estimate the
cost of different forms of the computation, which might include branches
and which may include edge probabilty information.
If you're looking at that and thinking it doesn't sound much different from
our current call to BRANCH_COST, you're right. This isn't as large a
departure from the existing cost model as I had originally intended.
Perhaps not as large of a change as you intended, but I think you're
hitting the key issue with BRANCH_COST.
This act of making the cost models consistent will cause code generation
changes on a number of targets - most notably x86_64. On x86_64 the RTX
cost of a conditional move comes out at "20" - this is far higher than
COSTS_N_INSNS (BRANCH_COST) for the x86 targets, so they lose lots
of if-conversion. The easy fix for this would be to implement the new hook.
I measured the performance impact on Spec2000 as a smoke test, it didn't
seem to harm anything, and the result was a slight (< 3%) uplift on
Spec2000FP. I'm no expert on x86_64, so I haven't taken a closer look for
the reasons.
I'd be comfortable with Uros guiding the implementation of the target
hook for x86 so that we don't take a major step backward.
Jeff