On Jul 9, 2014, at 8:21 AM, David Malcolm <dmalc...@redhat.com> 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?]
>From what I can tell these are remnants from the early days of haifa-sched
>(10+ years ago). I would be very surprised if scheduler didn't ICE on a
>PARALLEL of INSNs (not to be confused with a PARALLEL as INSN_PATTERN).
>
> 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.
Yes, it is correct.
>
> Similarly, do the first and third params of TARGET_SCHED_ADJUST_COST
> also satisfy INSN_CHAIN_CODE_P?
>
Yes, since they are always derived from DEP_CON / DEP_PRO.
--
Maxim Kuvyrkov
www.linaro.org
