This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch][Ping #3] PR80929: Realistic PARALLEL cost in seq_cost.
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: "avr at gjlay dot de" <avr at gjlay dot de>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: nd <nd at arm dot com>, Jeff Law <law at redhat dot com>, "ian at airs dot com" <ian at airs dot com>
- Date: Wed, 28 Jun 2017 20:18:21 +0000
- Subject: Re: [patch][Ping #3] PR80929: Realistic PARALLEL cost in seq_cost.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Georg-Johann Lay wrote:
@@ -5300,6 +5300,9 @@ seq_cost (const rtx_insn *seq, bool spee
set = single_set (seq);
if (set)
cost += set_rtx_cost (set, speed);
+ else if (INSN_P (seq)
+ && PARALLEL == GET_CODE (PATTERN (seq)))
+ cost += insn_rtx_cost (PATTERN (seq), speed);
else
cost++;
insn_rtx_cost may return zero if it can't find something useful in the parallel,
which means it may return a lower cost and even zero. Not sure whether this
is important, but in eg. combine a cost of zero means infinite and so could have
unintended consequences. So incrementing cost with a non-zero value
if insn_rtx_cost == 0 would seem safer.
Also why does the else do cost++ and not cost += COSTS_N_INSNS (1)?
Wilco