This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 Jun 2017 15:45:23 +0100
- Subject: Re: [rtlanal] Do a better job of costing parallel sets containing flag-setting operations.
- Authentication-results: sourceware.org; auth=none
- References: <66275bc9-7d97-b990-4c86-2de1f4a6a2fa@arm.com> <20170619140802.GK16550@gate.crashing.org>
On 19/06/17 15:08, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 19, 2017 at 02:46:59PM +0100, Richard Earnshaw (lists) wrote:
>> Many parallel set insns are of the form of a single set that also sets
>> the condition code flags. In this case the cost of such an insn is
>> normally the cost of the part that doesn't set the flags, since updating
>> the condition flags is simply a side effect.
>>
>> At present all such insns are treated as having unknown cost (ie 0) and
>> combine assumes that such insns are infinitely more expensive than any
>> other insn sequence with a non-zero cost.
>
> That's not what combine does: it optimistically assumes any combination
> with unknown costs is an improvement.
Actually the logic is
int reject = old_cost > 0 && new_cost > old_cost;
So reject will never be true if old cost is zero.
R.
>
>> This patch addresses this problem by allowing insn_rtx_cost to ignore
>> the condition setting part of a PARALLEL iff there is exactly one
>> comparison set and one non-comparison set. If the only set operation is
>> a comparison we still use that as the basis of the insn cost.
>
> I'll test this on a zillion archs, see what the effect is.
>
> Have you considered costing general parallels as well?
>
>
> Segher
>