Hi Gerald / Diego,
I have made all the mentioned changes. I also shortened the
description like Diego mentioned by removing all the strings but kept
the caveats. I have not added a reference to the documentation because
i do not know what link to reference. The builtins are completely
documented in extend.texi.
I have attached the patch. If there are no further comments I will
submit this tomorrow.
Thanks,
-Sri.
On Mon, Aug 20, 2012 at 1:31 PM, Gerald Pfeifer <[email protected]> wrote:
> Hi Sriraman,
>
> On Fri, 10 Aug 2012, Sriraman Tallam wrote:
>> I have added a release note for x86 builtins __builtin_cpu_is and
>> __builtin_cpu_supports. They were checked in to trunk in rev. 186789.
>
> I had hoped one of the x86 maintainers would review this from his
> perspective given that they have more background. For the lack of
> that, let me give it a try.
>
> Index: changes.html
> ===================================================================
> + <li> New builtin functions to detect run-time CPU type and ISA:<br>
>
> "built-in", cf. http://gcc.gnu.org/codingconventions.html; here and
> in the following.
>
> No <br> here; <ul> should just do that.
>
> + <ul>
> + <li>Builtin <code>__builtin_cpu_is</code> has been added to detect if
> + the run-time CPU is of a particular type. The builtin returns a postive
> + integer on a match and zero otherwise. The builtin accepts one string
> + literal argument, the CPU name. For example,
>
> "A built-in function..."
>
> "positive"
>
> "It accepts one string" (to make this shorter)
>
> + <code>__builtin_cpu_is("westmere")</code> returns a postive integer if
>
> "positive"
>
> + the run-time CPU is an Intel Corei7 Westmere processor. The following
>
> I don't work for Intel, but should there be a space before "i7"?
>
> + are the CPU names recognized by <code>__builtin_cpu_is:</code>
>
> How about making this "The following are the CPU names recognized for
> now", which avoids another reference to the name of the built-in and
> makes it clear that this is subject to change.
>
> + <li>Builtin <code>__builtin_cpu_supports</code> has been added to
> detect
>
> "A built-in function..."
>
> + returns a postive integer on a match and zero otherwise. The builtin
>
> "positive"
>
> + following are the ISA features recognized by
> + <code>__builtin_cpu_supports:</code>
>
> Same is above?
>
> + <p>Caveat: If the above builtins are called before any constructors are
> + invoked, like during IFUNC initialization, then the CPU detection
> + initialization must be explicity run using this newly provided
> + builtin, <code>__builtin_cpu_init</code>.
>
> "...using the new built-in function <code>__builtin_cpu_init</code>."
>
> What is a constructor in this context, by the way? Will this be clear
> to all the users?
>
> + <code>
> + static void (*some_ifunc_resolver(void))(void)<br>
> + {<br>
> +    __builtin_cpu_init();<br>
> +    if (__builtin_cpu_is("amdfam10h") ...<br>
> +    if (__builtin_cpu_supports("popcnt") ...<br>
> + }
> + </code>
>
> How about using <pre> here? That avoids the <br/>s which will cause
> problems with the web page validator, by the way.
>
>
> Nice job for documenting this so well. Thanks for taking the time
> and your patience!
>
> The patch is fine modulo the changes I pointed out (though some of
> them are more suggestions and you do not need to slavishly follow
> those).
>
> Gerald
Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.10
diff -u -r1.10 changes.html
--- changes.html 10 Aug 2012 16:25:46 -0000 1.10
+++ changes.html 21 Aug 2012 02:38:40 -0000
@@ -92,6 +92,38 @@
wrong results. You must build all
modules with <code>-mpreferred-stack-boundary=3</code>, including any
libraries. This includes the system libraries and startup modules.</li>
+ <li> New built-in functions to detect run-time CPU type and ISA:
+ <ul>
+ <li>A built-in function <code>__builtin_cpu_is</code> has been added to
+ detect if the run-time CPU is of a particular type. It returns a
+ positive integer on a match and zero otherwise. It accepts one string
+ literal argument, the CPU name. For example,
+ <code>__builtin_cpu_is("westmere")</code> returns a positive integer if
+ the run-time CPU is an Intel Core i7 Westmere processor. Please refer
+ to the documentation for the list of valid CPU names recognized.</li>
+ <li>A built-in function <code>__builtin_cpu_supports</code> has been
+ added to detect if the run-time CPU supports a particular ISA feature.
+ It returns a positive integer on a match and zero otherwise. It accepts
+ one string literal argument, the ISA feature. For example,
+ <code>__builtin_cpu_supports("ssse3")</code> returns a positive integer
+ if the run-time CPU supports SSSE3 instructions. Please refer to the
+ documentation for the list of valid ISA names recognized.</li>
+ </ul>
+ <p>Caveat: If these built-in functions are called before any static
+ constructors are invoked, like during IFUNC initialization, then the CPU
+ detection initialization must be explicity run using this newly provided
+ built-in function, <code>__builtin_cpu_init</code>. The initialization
+ needs to be done only once. For example, this is how the invocation would
+ look like inside an IFUNC initializer:</p>
+ <pre>
+ static void (*some_ifunc_resolver(void))(void)
+ {
+ __builtin_cpu_init();
+ if (__builtin_cpu_is("amdfam10h") ...
+ if (__builtin_cpu_supports("popcnt") ...
+ }
+ </pre>
+ </li>
</ul>
<h3 id="mips">MIPS</h3>
