[Bug target/95775] New: Command line argument for target_clones?

[Bug target/95775] New: Command line argument for target_clones?

[yyc1992 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775

            Bug ID: 95775
           Summary: Command line argument for target_clones?
           Product: gcc
           Version: 10.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

Would it make sense to add a command line argument that is roughly equivalent
to to adding `target_clones` to all functions?

In terms of usefulness, I believe it will be a very cheap way for many
libraries to turn on the support with minimal code change. It certainly won't
be as optimized as best possible but neither is target_clones attribute itself
compared to hand wrote different implementations using compiler
intrinsics/assembly...

In terms of implementation, I believe most of the issues I've hit when adding
such attribute to functions has been fixed so I have little issue using it now.
It'll also be a new feature so it shouldn't really break any existing code.

And for further improvement, the compiler should have fair knowledge of what
instruction can be/has been used and can omit some of the cloning in order to
reduce code size. I don't think this needs to be included in the first version
though...

And IIUC this is something that icc does automatically? (If that can serve as a
argument for this feature...)

[Bug ipa/95775] Command line argument for target_clones?

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
          Component|target                      |ipa
           Severity|normal                      |enhancement

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
But it will blow up code-size considerably.  Eventually with -flto and the
library constraining on what symbols it exports one could figure the
minimal set of functions with IFUNC relocations at least.  Using
profile-feedback
might also able to concentrate on interesting functions.

So without some major work I don't think simply slapping target_clones on
each function is going to fly in practice.

Eventually it should be possible to do sth like target_clones(auto) where
with a new option, the target (or the user) can define "default" targets
to clone for but the user still figures which are the important functions
to optimize [and GCC may, via IPA "spread" the cloned cgraph portion a bit].

[Bug ipa/95775] Command line argument for target_clones?

[yyc1992 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775

--- Comment #2 from Yichao Yu <yyc1992 at gmail dot com> ---
> But it will blow up code-size considerably.
> So without some major work I don't think simply slapping target_clones on each function is going to fly in practice.

I mean, it'll blow up not much more than the number of targets. I do agree this
is not something that the compiler should just do automatically and especially
not for big libraries and the user has to ask for it.

However, I don't believe code side consumes most memory on any modern desktop
or server systems and when using shared library different process won't even
consume much more memory anyway. It's for sure still the user's choice but OTOH
I think the compiler shouldn't have to make this choice for the user.

Additionally, there are some libraries, like math heavy ones, where virtually
every single functions could benefit from this. Those are the ones that I would
like to apply this option too. I'm also hoping, and I forgot to mention this in
the first post, that this can just work on gfortran as well...

> Eventually it should be possible to do sth like target_clones(auto) where with a new option, the target (or the user) can define "default" targets to clone for but the user still figures which are the important functions to optimize

In julia I'm currently using a simple heuristic of detecting floating point
operation, vector operation and loops...

> [and GCC may, via IPA "spread" the cloned cgraph portion a bit].

and I do this in julia too.

[Bug ipa/95775] Command line argument for target_clones?

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Hey. My opinion is similar to Richi's. If you really want a highly optimized
library, you should rather use a dlopen mechanism with pre-built set of
options.

[Bug ipa/95775] Command line argument for target_clones?

[yyc1992 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775

--- Comment #4 from Yichao Yu <yyc1992 at gmail dot com> ---
> Hey. My opinion is similar to Richi's. If you really want a highly optimized library, you should rather use a dlopen mechanism with pre-built set of options.

Well, a few things,

1. That sounds like an argument against `target_clone` and `target`. If
dlopen'ing different libraries is your recommended solution then none of these
would be needed.
2. The solution you propose put all the pression on the user of the library.
That has a few problems.

   2.1. There are strictly more users than libraries. (Assuming the library is
used at all) so this is forcing more (repeated) work to be done.
   2.2. The author of the library and to a lesser degree the builder of the
library has the best knowledge of the set of features that can benefit the
library/the most useful for the deployment environment. The author of the user
code of the library, who has to implement the dispatch/loading logic in general
has much less complete knowledge of what the target to support.
   2.3. It'll be even worse for code size since this forces each user to carry
their own library, and now all data has to be duplicated as well in additional
to code. Also because,

3. There's no standard way of doing this AFAICT.

Now (3) is really the main point.
I'm fine with whatever mechanism that allows multiple versions of the code to
be available as long as it requires no more effort/cost from/for the user (and
to a lesser degree the author) of the library.

If one such mechanism is provided by gcc/glibc/binutils so that library writers
don't have to invent their own loading and detection mechanism and won't cause
unnecessary indirection (as cheap as ifunc) and will just work for the user to
either link or dlopen, then I think it doesn't really matter if that's backed
by one file/multiple files or whatever one can come up with.

Currently, the only mechanism available that fits this description AFAICT is
`target_clones`/`ifunc`. Unless there's a roadmap that I'm not aware of to
replace this mechanism with a similar one backed by multiple files I don't
think suggesting such a mechanism is the right approach.

Again, I said in the very first post that I totally agree this won't be the
method to give absolutely the best performance, but neither is `target_clones`.
I also completely agree that this option can be misused and the compiler should
not do it on its own before getting smarter but this is far from the first
option that can be misused and given how cheap memory is and how multiple load
of the same library doesn't take more memory this isn't even closoed to be the
worse misused either.