avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Re: bugfix for cselib_invalidate_regno


From: Richard Earnshaw
Subject: [avr-gcc-list] Re: bugfix for cselib_invalidate_regno
Date: Fri, 23 May 2003 10:45:28 +0100

> Richard Earnshaw <address@hidden> writes:
> 
> > > Denis Chertykov <address@hidden> writes:
> > > 
> > > > I have founded a bug in cselib.c:cselib_invalidate_regno.
> > > > The avr port triggers this bug.
> > > > Current version of cselib_invalidate_regno didn't invalidate lower
> > > > register numbers if they contain values that overlap REGNO in case
> > > > that (regno < FIRST_PSEUDO_REGISTER && mode == VOIDmode). This happens
> > > > if cselib_invalidate_regno called from cselib_process_insn which
> > > > handle CALL_INSN.
> > > > IE
> > > > 
> > > >   /* If this is a call instruction, forget anything stored in a
> > > >      call clobbered register, or, if this is not a const call, in
> > > >      memory.  */
> > > >   if (GET_CODE (insn) == CALL_INSN)
> > > >     {
> > > >       for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> > > >         if (call_used_regs[i])
> > > >           cselib_invalidate_regno (i, VOIDmode);
> > > > 

> > 
> > Why not change the caller to pass reg_raw_mode[regno].  That seems much 
> > cleaner to me than pretending a hard register can have no mode.
> 
> Because my patch make cselib_invalidate_regno more universal.
> Your example will work with my patch too.
> 

No it doesn't.  At least, not unless we agree that we want this meaning to 
exist everywhere.  There's nothing in the documentation that says that a 
hard register in mode VOIDmode has its natural size.  So all you are doing 
here is adding an undocumented local convention.  I dislike that strongly.

> cselib_invalidate_regno have only two callers, are you sure that the
> second always pass the mode != VOIDmode ?

IMO cselib_invalidate_regno should abort if passed VOIDmode for a hard 
register.  As things stand at present it's meaningless.

R.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]