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: thanks for the memory work


On Tue, 2003-11-25 at 18:54, Jan Hubicka wrote:
> > In message <200311260003.49376.s.bosscher@student.tudelft.nl>, Steven Bosscher 

> >  >are redundant our purpose, there's less than 8 MB overhead from this.
> > Rather than focus on the waste within the varray, maybe the focus should
> > be on not creating the varray in the first place.
> > 
> > The overwhelming majority of statements produce a single output -- the
> > only reason def_ops is a varray is to handle those oddball cases like
> > asms which can have multiple outputs.
> > 
> > So an interesting question then becomes can we _cleanly_ avoid use of the
> > varray in the general case.   That would reduce the number of operand varrays
> 

We can.

> I think the iterator API + some magic to recognize most common cases
> would do the job here.  I plan to look into this once I get my patches
> queue shorter, but I won't mind anyone beating me :)
> 

I think we'll pay a penalty if we don't cache the information and
instead try to recreate it each time, even for the common cases. Too
many ifs executed all the time. I certainly write code assuming that use
and def access is quick.

As I discussed earlier, I plan to make all the real USE and DEF ops for
all the stmt's come out of a single array, or be cached in the
annotation for the common case like immediate_uses works now. Whichever
works out best.  

Im in the middle of abstracting out the real and virtual uses into their
own types to facilitate this now.

Andrew


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