Jeff Law
2014-10-01 22:34:16 UTC
This was inspired by a discussion with Felix who was making changes in
this area.
Basically this promotes the "init_insns" field within struct equivalence
from an rtx to an rtx_insn_list.
The only thing that's really interesting here is the old code exploits
the fact that we could put any RTX in the list by shoving const0_rtx
into the init_insns list as a marker to indicate we've already
determined the relevant pseudo must not have an equivalence.
Thus we could have the following objects in the init_insns field:
NULL
const0_rtx
INSN_LIST ...
This patch uses INSN_LIST (NULL_RTX, NULL) as the special marker. Thus
the only two things that would exist in the init_insns field would be
NULL or an INSN_LIST. Goodness.
Rather than stash away the special marker INSN_LIST into a global
variable or something similar, we instead to do a two step check for the
marker. First verify that the insn_list field is non-NULL, then look at
the first insn in the list and see if that is NULL.
Bootstrapped and regression tested on i686-unknown-linux-gnu and
x86_64-unknown-linux-gnu.
Ok for the trunk?
Jeff
this area.
Basically this promotes the "init_insns" field within struct equivalence
from an rtx to an rtx_insn_list.
The only thing that's really interesting here is the old code exploits
the fact that we could put any RTX in the list by shoving const0_rtx
into the init_insns list as a marker to indicate we've already
determined the relevant pseudo must not have an equivalence.
Thus we could have the following objects in the init_insns field:
NULL
const0_rtx
INSN_LIST ...
This patch uses INSN_LIST (NULL_RTX, NULL) as the special marker. Thus
the only two things that would exist in the init_insns field would be
NULL or an INSN_LIST. Goodness.
Rather than stash away the special marker INSN_LIST into a global
variable or something similar, we instead to do a two step check for the
marker. First verify that the insn_list field is non-NULL, then look at
the first insn in the list and see if that is NULL.
Bootstrapped and regression tested on i686-unknown-linux-gnu and
x86_64-unknown-linux-gnu.
Ok for the trunk?
Jeff