Why isn't gcc designed to use option boundary only for targets in target_clones attribute?

[Mingye Wang (Arthur2e5)]

On 16/12/13 16:21, Evgeny Stupachenko wrote:
> 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".

My experiments with an (service as a software alternative) copy of gcc 
6.2.0 in [1] seems to separate "tune=" clones and actually generate 
different code. You can see only the generic version generates the `rep 
ret` pattern, which seems to be generally known as a workaround for AMD 
CPUs.

   [1]: https://godbolt.org/g/o3xTaj

But whether gcc would actually dispatch to tuned variants is what 
determines whether this clone will be run, so yes I should just skip it 
for now. (Should I write a feature request, though?)

> With above your example becomes "sse3", "default" and
> "arch=ivybridge". Which could be implemented with current algorithm.

True. Could have done it with easier things...

> 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.

Right... But on the other hand, it's possible, however, that inlining 
will eventually have to deal with sets of instruction sets to 
effectively combine `arch=` definitions.

> 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.

A probable use case for such fine-grained control may be found in MIPS. 
One may pass `no-branch-likely` for MIPS or similar options that 
disables instructions removed in later revisions to achieve better 
upward compatibility, but still wants `branch-likely` in order to use 
`fix-r10000`. Arguably one can avoid this by just using `arch=` in many 
cases.

--
Thanks,

Arthur2e5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20161214/7a10f8af/attachment-0001.sig>