This is the mail archive of the gcc@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]
Other format: [Raw text]

Re: must_alias question


> On Thu, 2003-11-20 at 19:47, Jan Hubicka wrote:
> > > On Thu, 2003-11-20 at 16:44, Jan Hubicka wrote:
> > > 
> > > > The bug is probably reason for the FIXME disabling the function for
> > > > pointer types BTW :)
> > > >
> > > Bonus!
> > > 
> > > 
> > > >  I will test all the changes I cumulated for mustalias pass.
> > > > I think we can kill ADDRESSOF beast now that will make things a lot
> > > > easier.
> > > > 
> > > OK.  I'm very interested in these changes.  We need to be able to remove
> > > the FIXME in promote_var safely.  Otherwise, we miss several
> > > scalarizations that are important to finish fixing PR 12747.
> > 
> > I think I noticed another must_alias bug. flor local static variables we
> > may suceed to elliminate all ADDR_EXPRs for given variable in one inline
> > copy, but not in the otehrs, so the function remains call clobbered.
> > Does disabling promote_vars for static functions look like the way to
> > go? 
> > 
> You mean 'static variables' here?
> 
> So, we are promoting a static variable in some instantiations of an
> inlined function and not in others?  Hmm, perhaps we could just refrain
Yes.
> from clearing the TREE_ADDRESSABLE bit.  Do you have a test case?
No, I found this during proofreading the code, but it is not dificult to produce one.

Honza
> 
> 
> Diego.


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