This is the mail archive of the gcc-patches@gcc.gnu.org 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]

Re: PATCH to remove unnecessary NOTE_INSN_DELETED


> In message <199911041202.MAA14712@cam-mail1.cambridge.arm.com>you write:
> > > >  Why don't we just add another uid field to every insn?  We'd have
> > > > one that    stays constant during the entire compilation (for rtl 
> > > > dumps and debugging), and one that can get renumbered at any time.  
> > 
> > > As you mentioned, we could do it for regs too.
> > 
> > Would that mean we can keep the pseudo number after reload?  That would be 
> > sooo useful at times.
> I can't see a reason why not.
> 
> We'd just copy the pseudo # into that additional field during alter_reg.

I was thinking along the lines of (reg regnum assignednum) where regnum is 
the original number assigned to the reg at its creation, and assigned num 
is the currently assigned number; during reload the register would get 
assigned a hard register and the assignednum would become the hard 
register number.  Assigned num is the number that would get munged as 
appropriate to reduce space.

> 
> I'm curious, what do you want the original pseudo # for?  [ I'm guessing you
> want to peek at something like REGNO_POINTER_FLAG or REGNO_POINTER_ALIGN? ]

Well mainly when I'm trying to debug something in reload: I still find it 
confusing when the pseudos all disappear half-way through the pass.  It 
would also be useful for tracking the purposes of reload insns that get 
inserted in the chain, since we would then see something like

	(set (mem()) (reg 88 75))

get reloaded to 
	(set (reg 88 9 r9) (mem(plus (reg 13 13 sp) (const_int 32))))
	(set (mem()) (reg 88 9 r9))

and it would be then more easy to track back to the original code when 
things go wrong.

However, your suggestion about being able to reference REGNO_POINTER_* 
after reload might lead to some interesting peephole opportunities if the 
information could be guaranteed to be still reliable.

R.




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