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 [1] 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 [2] has
this expressed in the type system as of [3], 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.
Jeff
