This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [2/4] SMS: Use ids to represent ps_insns
Ayal Zaks <ayal.zaks@gmail.com> writes:
> So instead of navigating directlyÂfrom
> ps_insn->ddg_node->node_sched_params, we now use indices and lookup
> pointees in ddg_node and node_sched_params arrays. A bit of a
> nuisance, but it's ok with me.
Well, IMO, ps_insn->ddg_node->node_sched_params is the same amount
of indirection as node_sched_params[ps_insn->id].
> o One could still achieve the goal of having ps_insn's with
> node_sched_params but free of ddg_node's, w/o penalizing the existing
> direct access from ddg_node->node_sched_params, and w/o replicating
> the interface.ÂIf youÂadd an (insn field and an) aux union to ps_insn,
> whose info points to your node_sched_params, you could reuse the same
> set of macros. Admittedly, it's aÂspace-time tradeoff, where the space
> is probably not a major concern, and there are other places to look
> for first in sms to save time.
I'm not sure what you mean by "replicating the interface". There's
still only one interface for getting schedule params: everything still
goes through the SCHED_* macros.
If anything, I think having a way of going directly from the ps_insn to
the sched params _would_ replicate the interface, because some parts of
SMS want the scheduling parameters for a ddg node rather than a ps_insn.
So some parts would (presumably) still use SCHED_* macros for a node,
while the rest would use some other interface for ps_insns.
But I'll do that if you think it's better. If we do, I think we
should remove the current SCHED_* macros and just have one that
goes from a ddg node to the parameters structure itself.
So SCHED_TIME (node) becomes SCHED_PARAMS (node)->time, etc.
Code that operates on ps_insns could just use pi->sched_params->time.
But if we want to keep SCHED_TIME, etc., macros that can be used for
everything, then I don't see how changes to ps_insn would help.
> o first_reg_move and nreg_moves will be redundant for regmoves, right?
> No refactoring is perfect...
After the patches, they're only there for debugging. I did wonder
whether I should just remove them.
> o it could be useful to have a debug version which checks array
> bounds, in case one feeds a bad index.
FWIW, VEC does this for us.
> o and a minor comment below:
>
>> /* The scheduling parameters held for each node. */
>> typedef struct node_sched_params
>> {
>> - int asap; /* A lower-bound on the absolute scheduling cycle. */
>> int time; /* The absolute scheduling cycle (time >= asap). */
>
> Please fix/remove theÂ"(time >= asap)" comment, as there's no asap
> there any more.
OK.
Richard