This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] data prefetch support and __builtin_prefetch (take 2)
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Janis Johnson <janis187 at us dot ibm dot com>, nickc at redhat dot com
- Cc: Richard dot Earnshaw at arm dot com, gcc-patches at gcc dot gnu dot org
- Date: Wed, 05 Dec 2001 17:49:49 +0000
- Subject: Re: [PATCH] data prefetch support and __builtin_prefetch (take 2)
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > 1) The arm.md already has a "prefetch" expander that takes a different
> > number of arguments. (I can fix this, but it should have been fixed in
> > the above check-in).
>
> Sorry, I should have done more searching for possible conflicts. Let's
> get the next piece figured out and then you can let me know whether you
> want me to fix this or do it yourself.
As much as anything, these problems should have been caught during the
review process; particularly as this defines a new generic builtin. I've
been away for the last month, so out of touch. How thoroughly was the
spec for this builtin examined? It wouldn't be good if we found we needed
a further argument a couple of releases from now.
With respect to the internal problems, I'll fix them -- I've probably got
more facilities for testing the ARM changes than you have ;-)
>
> > 2) ARM targets already have a __builtin_prefetch function that takes one
> > argument; as far as I can tell your new implementation will mean an API
> > change for users of gcc-3.0
>
> I looked through all of the documentation to see if there was existing
> prefetch support and all I found was __builtin_ia32_prefetch. Now I'll
> know to look through the target-dependent code, too, for undocumented
> builtin functions.
>
> I suppose it's too much to hope for that since it's not documented, no
> one knows about it and it's not being used.
Possibly, I've no idea. I think it was the Cygnus/Red Hat guys who added
this. Nick, any idea if this feature is widely used by your customers?
> Assuming, though, that it is being used, do I need to change the name of
> the new generic builtin to avoid conflicting, or is the use limited to a
> small amount of code within ARM so the existing uses could be changed?
> __builtin_prefetch is such an obvious choice for a name, but I can start
> thinking about alternatives.
It might also be possible to do some overloading (ie allow both
__builtin_prefetch(addr) and __builtin_prefetch(addr, rw, loc) ), but I
don't know if the compiler will allow that. It's not something I would
generally like to see in a C compiler, but the first argument is the same
in both cases...