This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]