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]
Other format: [Raw text]

Re: preliminary patch: prefetch support for i386


> On Sat, Dec 01, 2001 at 12:54:37AM +0100, Jan Hubicka wrote:
> > > On Fri, Nov 30, 2001 at 09:18:19PM +0100, Jan Hubicka wrote:
> > > > first of all, thanks for the patch. It is something I really
> > > > wanted to do for long time.
> > > 
> > > I know, I'm hoping that the existence of a general framework will
> > > inspire you to update your prefetch optimizations for arrays in loops
> > 
> > I will install your updated patch to cfg-branch. As 3.1 is feature freezing at
> > 15th, we have some time for 3.2.x release. I hope that we will get working CFG
> > based loop optimizer till then and working AST loop optimizer as well. The
> > prefetch code then should recognize the possiblities at tree level and emit
> > prefetches at lower level, most probably.
> 
> First I'd like to update it again; the term "straddle" appears in a few
> variables names and should be replaced with "stride", and I think there
> were some other things I didn't get to yet.
> 
> Is that patch likely to be stable enough to go into 3.1, with specific
> performance tweaks added later?  The bulk of the code is only used with
> a new optimization option, so it shouldn't hurt anything that doesn't
> use that option.

Here probably Richard or someone needs to decide.  While the patch appears
to work fine, the main problem I see is that it is limited in scope - it
does not do the analysis at full loop nest and it use the dying loop optimizer
framework. At time it has been made this has been about the only sollution,
now gcc has chance to get more far with the new dependency code, AST loop
optimizer and low level loop optimizer Michael has started work on (and Zdenek
and me are concentrating on it now at the cfg-branch development).

So for 3.2, the patch will need major redesign once the infrastructure is
ready. For 3.1 it isn't and the patch is pretty harmless adding wanted
feature, so if someone with review rights says that it is possible to
get the patch in, at least, as 3.1 temporary sollution, I will happily
update it and send for review.
> 
> > > and perhaps greedy prefetching of addresses in pointers!  Please let me
> > 
> > I still have the primitive code to do that.  What is missing is to recognize
> > the pointers in structures whose addresses are fetched and prefetch them.
> > I am not sure this indirection is correct in C.  May I assume that if
> > I have pointer to structure and I know that program reads some of it's fields,
> > the other fields are accessible too?
> 
> The new prefetch rtl code is defined to use only non-faulting prefetch
> instructions and this optimization will not be turned on by default, so
> C correctness isn't an issue, is it?

Only issue is, as with any loop optimizing code in gcc, that it needs to be
done properly later and that needs big effort that blocks the development
almost completely.

Honza


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