On Tue, Mar 13, 2018 at 9:32 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Mar 13, 2018 at 09:24:11AM +0100, Martin Liška wrote: >> On 03/12/2018 10:39 AM, Marc Glisse wrote: >> > On Mon, 12 Mar 2018, Martin Liška wrote: >> > >> > > This is fix for the PR that introduces a new target macro. Using the >> > > macro >> > > one can say that a target has a fast mempcpy and thus it's preferred to >> > > be used >> > > if possible. >> > > >> > > Patch can bootstrap on ppc64le-redhat-linux and survives regression >> > > tests. >> > > I also tested on x86_64-linux-gnu. >> > > >> > > Ready to be installed? >> > > Martin >> > > >> > > gcc/ChangeLog: >> > > >> > > 2018-03-08 Martin Liska <mli...@suse.cz> >> > > >> > > PR middle-end/81657 >> > > * builtins.c (expand_builtin_memory_copy_args): Add new >> > > arguments. >> > > * config/i386/i386.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE): >> > > New macro. >> > >> > Shouldn't the macro be defined in a more specific case, for instance glibc >> > on x86? Or do all known libc on x86 happen to provide a fast mempcpy? >> >> That's Marc a very good question. Do we already have a glibc-related target >> macros/hooks? >> If so, I would add this as one of these. > > Yes, see e.g. TARGET_LIBC_HAS_FUNCTION target hook, > where in particular linux_libc_has_function deals with various C libraries. > Of course, in this case you need another target hook, that is dependent both > on the target backend and C library. > > It would be nice to make the target hook a little bit more generic as well, > e.g. pass it enum builtin_function and query if it is fast, slow or > unknown, or even some kind of cost, where the caller could ask for cost of > BUILT_IN_MEMCPY and BUILT_IN_MEMPCPY and decide based on the relative costs.
Or maybe a hook returning the alternative to use? Pass it BUILT_IN_X and get back the same or related builtin? Richard. > Jakub
