This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed targets to deprecate for 3.4
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, Nathanael Nerode <neroden at twcny dot rr dot com>, <gcc at gcc dot gnu dot org>
- Date: Wed, 1 Oct 2003 18:13:51 -0400 (EDT)
- Subject: Re: Proposed targets to deprecate for 3.4
On Wed, 1 Oct 2003, Richard Henderson wrote:
> On Wed, Oct 01, 2003 at 03:11:00AM -0400, Hans-Peter Nilsson wrote:
> > Hmm, maybe both uses could be replaced with unspec_volatile
> > insns. Can the scheduler still move insns past an unspec_volatile?
>
> We never moved insns past unspec_volatile.
Sorry, the word "still" wasn't meant to refer to historic gcc; I
meant to refer to whether the scheduler was able to freely move
insns "still" after a change to this mechanism. Not that it
matters for MMIX, but I guess it would for alpha (if replacing
the TARGET_ASM_FUNCTION_END_PROLOGUE code with an unspec* that
outputs the ".prologue N" pseudo).
> As for the rest of the register renaming thing, perhaps
> LEAF_REG_REMAP could be extended to indicate the results
> of prologue_epilogue_contains or some other predicate.
I'm willing to investigate, but I can't see what LEAF_REG_REMAP
could add to this, for one because the remapping doesn't occur
for leaf-functions. Do you mean something *like* L_R_R? If so,
I'm hesitant to introduce another macro just for the benefit of
MMIX when it can be solved by other means. The maintenance
cost, you know. ;-)
I think I'll try RTX_FRAME_RELATED_P or just a pair of unspec:s.
Hmm, how do I find the current insn to apply RTX_FRAME_RELATED_P
on, calling it from various register-number-outputting machine
macros? Ok, unspec:s it'll be, then.
brgds, H-P