> So take __attribute__((target_clones("sse3,tune=generic,default",
> "arch=ivybridge"))) as an example. Instead of creating two clones with
> targets "sse3,tune=generic,default" and "arch=ivybridge" respectively,
> GCC's target_clones would create three clones with their targets defined
> as "sse3" "default", "tune=generic", and "arch=ivybridge". This
> behavior, although documented somehow, is confusing.
First, to be able to run a function through resolver we always need
"default" as separate target.
As for separating. As far as I understand all "arch" options assumes
the same tuning. So you can skip "tune=generic".
With above your example becomes "sse3", "default" and
"arch=ivybridge". Which could be implemented with current algorithm.
The other point is inlining. It is clear when you have just 1 option:
foo() for sse3 could be inlined into bar() for sse3, but not into
bar() for sse2.
If we have multiple options it is harder to inline.
So multiple options are doable, but right now I don't see a
significant reason for this. If you have some source code example
where it is better that would be great.
Thanks,
Evgeny
On Tue, Dec 13, 2016 at 1:50 AM, Mason <slash.tmp@xxxxxxx> wrote:
> On 13/12/2016 02:36, Mingye Wang (Arthur2e5) wrote:
>
>> GCC 6's __attribute__((target_clones)) feature looks quite exciting to
>> me, but I cannot understand why it is designed to take, say, a single
>> string option like "sse2,avx2" and make it two separate
>> __attribute__((target)) clones. Using commas in single option strings
>> sounds like defeating the whole purpose of allowing multiple options;
>> furthermore, after some inspection on the source, it seems that all the
>> options will be smashed together with a comma and processed as a single
>> string.
>>
>> So take __attribute__((target_clones("sse3,tune=generic,default",
>> "arch=ivybridge"))) as an example. Instead of creating two clones with
>> targets "sse3,tune=generic,default" and "arch=ivybridge" respectively,
>> GCC's target_clones would create three clones with their targets defined
>> as "sse3" "default", "tune=generic", and "arch=ivybridge". This
>> behavior, although documented somehow, is confusing.
>>
>> Could anyone please tell me why GCC decided to go with such "smash the
>> string options together and split later" design? Is it possible to have
>> GCC change this behavior in later releases, if it is indeed a design flaw?
>
> Hello,
>
> Out of curiosity, I took a peak at the source code.
> (1.6 GiB repo, clone requires 15 minutes on fast connection)
> $ git clone git://gcc.gnu.org/git/gcc.git
>
> AFAICT (?) the implementation is in gcc/multiple_target.c
>
> Likely candidates are ab50af2a61a65 (initial) and
> cb6c05f855c41 (update).
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=229595
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242608
>
> I've CCed the respective authors.
>
> Regards.
>
