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/o3xTajBut 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
Attachment:
signature.asc
Description: OpenPGP digital signature
