mn10300, invariants on DEP_PRO/DEP_CON and on TARGET_SCHED_ADJUST_COST params

[David Malcolm <dmalcolm at redhat dot com>]

[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?

Thanks
Dave

[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01826.html
[2] http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v11/
[3]
http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v11/0157-Remove-DEP_PRO-CON-scaffolding.patch