On 3/2/2026 03:32, Sandra Loosemore wrote:
On 2/2/26 10:49, Yangyu Chen wrote:
This patch adds support for target_clones table option. The
target_clones table option allows users to specify multiple versions
of a function and select the version at runtime based on the specified
table.
I have some documentation nits to pick.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 58254b82b0e0..64e8ff190ab9 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -677,7 +677,7 @@ Objective-C and Objective-C++ Dialects}.
-fspeculatively-call-stored-functions -fsplit-paths
-fsplit-wide-types -fsplit-wide-types-early -fssa-backprop -fssa-
phiopt
-fstdarg-opt -fstore-merging -fstrict-aliasing -fipa-strict-aliasing
--fthread-jumps -ftracer -ftree-bit-ccp
+-ftarget-clones-table=@var{path} -fthread-jumps -ftracer -ftree-
bit-ccp
Multiple options on the same line in these tables should be separated by
two spaces; you've only added one after your new option.
Thanks! I will fix that in the next revision.
+@opindex ftarget-clones-table
+@item -ftarget-clones-table=@var{path}
+Read JSON formatted target_clone table to insert @code{target_clones}
+attribute to functions based on the table contents. Where @var{path}
is a
+file path to the JSON formatted target_clone table. When attribute
+@code{target_clones} is applied to a function, the compiler creates
+multiple versions of the function for different targets. When attribute
+@code{target_clones} also exist on the function definition, the targets
+specified in the attribute and the targets specified in the JSON
formatted
+target_clone table are merged.
I find this description really hard to parse. Does this replacement
text accurately capture what you want it to say?
Read target clone information from the JSON-formatted file at
@var{path}. This augments any explicit @code{target_clones} attributes
on functions named in the file, and results in multiple versions of the
function being created for different targets. @xref{Attributes}.
Thanks for the careful review! Indeed, these words are hard to parse.
Your replacement is great!
+
+This is useful when you want to optimize a function for different CPU
+features and select the appropriate version at runtime based on the CPU
+features of the machine the program is running on without source code
+modification.
+
+This table is formatted as:
+
+@smallexample
+@{
+ "mangled_function_name1": @{
+ "target1": ["attr1", ...],
+ ...
+ @},
+ ...
+@}
+@end smallexample
+
+For example, say you have a C++ function named @code{foo} with return
type
+@code{void} without parameters, and you want to clone it for targets
+@code{arch=x86-64-v3} and @code{arch=x86-64-v4} on x86-64 architecture.
+You can create a JSON formatted target_clone table file named
s/JSON formatted/JSON-formatted
+@file{target_clones.json} with the following contents:
+
+@smallexample
+@{
+ "_Z3foov": @{
+ "x86_64": ["arch=x86-64-v3", "arch=x86-64-v4"]
+ @}
+@}
+@end smallexample
+
+Then, you can use @option{-ftarget-clones-table=target_clones.json}
+to clone the function @code{foo} for the targets
+@code{arch=x86-64-v3} and @code{arch=x86-64-v4}. This is equivalent
+to adding the following attribute to the function definition:
+
+@smallexample
+#ifdef __x86_64__
+__attribute__ ((target_clones ("arch=x86-64-v3", "arch=x86-64-v4",
"default")))
+#endif
+void foo (void) @{ ... @}
+@end smallexample
+
+This design also support to have multiple architectures in the same JSON
+formatted target_clone table. For other architectures like aarch64 and
s/support to have/supports/
s/JSON formatted/JSON-formatted/
-Sandra
Thanks,
Yangyu Chen
