This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: mn10300, invariants on DEP_PRO/DEP_CON and on TARGET_SCHED_ADJUST_COST params
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- Cc: gcc at gcc dot gnu dot org, Nick Clifton <nickc at redhat dot com>
- Date: Fri, 11 Jul 2014 10:13:51 -0400
- 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> <159056FD-D942-4338-B2BC-A47EAB168FE8 at linaro dot org>
On Fri, 2014-07-11 at 10:13 +1200, Maxim Kuvyrkov wrote:
> On Jul 9, 2014, at 8:21 AM, David Malcolm <dmalcolm@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).
Thanks. In my experimental patch series [1] I've gone ahead and removed
those checks.
> > 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.
Thanks; that's reassuring.
> >
> > 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.
(nods)
Thanks again
Dave
[1] fwiw, latest work-in-progress of instructions vs expressions:
http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v12/
with the removal of the redundant checks for PARALLEL in:
http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v12/0205-FIXME-config-mn10300-Fix-for-target.def-patch.patch