This is the mail archive of the
mailing list for the GCC project.
Re: mn10300, invariants on DEP_PRO/DEP_CON and on TARGET_SCHED_ADJUST_COST params
- From: Jeff Law <law at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>, gcc at gcc dot gnu dot org
- Cc: Nick Clifton <nickc at redhat dot com>
- Date: Wed, 16 Jul 2014 18:50:30 -0600
- Subject: Re: mn10300, invariants on DEP_PRO/DEP_CON and on TARGET_SCHED_ADJUST_COST params
- Authentication-results: sourceware.org; auth=none
- References: <1404850873 dot 21706 dot 109 dot camel at surprise>
On 07/08/14 14:21, David Malcolm wrote:
[CCing nickc, who wrote the mn10300 hook in question]
I'm experimenting with separating out instructions from expressions in
RTL; see  for more info on that.
I noticed that mn10300 has this implementation of a target hook:
#define TARGET_SCHED_ADJUST_COST mn10300_adjust_sched_cost
Within mn10300_adjust_sched_cost (where "insn" and "dep" are the first
and third parameters respectively), there's this code:
if (GET_CODE (insn) == PARALLEL)
insn = XVECEXP (insn, 0, 0);
if (GET_CODE (dep) == PARALLEL)
dep = XVECEXP (dep, 0, 0);
However, I believe that these params of this hook ("insn") always
satisfy INSN_CHAIN_CODE_P, and so can't have code PARALLEL. [Nick: did
those conditionals ever get triggered, or was this defensive coding?]
Specifically, the hook is called from haifa-sched.c:dep_cost_1 on the
DEP_CON and DEP_PRO of a dep_t.
It's my belief that DEP_CON and DEP_PRO always satisfy INSN_CHAIN_CODE_P
- and on every other config so far that seems to be the case.
Is my belief about DEP_CON/DEP_PRO correct? (or, at least, consistent
with other gcc developers' views on the matter :)) My patch kit  has
this expressed in the type system as of , so if I'm incorrect about
this I'd prefer to know ASAP.
Similarly, do the first and third params of TARGET_SCHED_ADJUST_COST
also satisfy INSN_CHAIN_CODE_P?
I suspect these should be
if (GET_CODE (PATTERN (insn)) == PARALLEL)
and similarly for DEP
That way they're doing something sensible for define_insns which have
patterns that are PARALLELs (where typically the first element is the
only one that is interesting).
Feel free to make that change independent of the RTL classes work you're
doing and consider it pre-approved with some sensible sanity testing.