public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Meissner <meissner@linux.vnet.ibm.com>
To: Michael Meissner <meissner@linux.vnet.ibm.com>,
	       GCC mailing list <gcc@gcc.gnu.org>,
	       Segher Boessenkool <segher@kernel.crashing.org>,
	       David Edelsohn <dje.gcc@gmail.com>,
	Jan Hubicka <hubicka@ucw.cz>,
	       Uros Bizjak <ubizjak@gmail.com>,
	       Kirill Yukhin <kirill.yukhin@gmail.com>,
	       Richard Biener <rguenther@suse.de>,
	Richard Henderson <rth@redhat.com>,
	       Jakub Jelinek <jakub@redhat.com>,
	       Richard Earnshaw <richard.earnshaw@arm.com>,
	       Marcus Shawcroft <marcus.shawcroft@arm.com>,
	       Nick Clifton <nickc@redhat.com>,
	       Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	       Bernd Schmidt <bschmidt@redhat.com>,
	Jeff Law <law@redhat.com>,
	       Hartmut Penner <hepenner@us.ibm.com>,
	       Ulrich Weigand <uweigand@de.ibm.com>,
	       Andreas Krebbel <Andreas.Krebbel@de.ibm.com>,
	       Evgeny Stupachenko <evstupac@gmail.com>
Subject: Re: GCC target_clone support (functionality question)
Date: Fri, 05 May 2017 18:45:00 -0000	[thread overview]
Message-ID: <20170505184530.GA15560@ibm-tiger.the-meissners.org> (raw)
In-Reply-To: <20170505181859.GA11428@ibm-tiger.the-meissners.org>

This message is separated from the question about moving code, as it is a
questions about the functionality of target_clone support.

Right now it looks like target_clone only generates the ifunc handler if there
is a call to the function in the object file.  It does not generate the ifunc
handler if there is no call.

For the default function, it generates the normal name.  This means that any
function that calls the function from a different object module will only get
the standard function.  From a library and user perspective, I think this is
wrong.  Instead the default function should be generated with a different name,
and the ifunc function should list the standard name.  Then you don't have to
change all of the other calls in the object file, the normal ifunc handling
will handle it.  It also means you can more easily put this function in a
library and automatically call the appropriate version.

Do people agree with this assessment, and should I change the code to do this
(for both x86 nd ppc targets)?  If not, what is the reason for the objection?

Consider mvc5.c from the testsuite:

	/* { dg-do compile } */
	/* { dg-require-ifunc "" } */
	/* { dg-options "-fno-inline" } */
	/* { dg-final { scan-assembler-times "foo.ifunc" 6 } } */

	__attribute__((target_clones("default","avx","avx2")))
	int
	foo ()
	{
	  return 10;
	}

	__attribute__((target_clones("default","avx","avx2")))
	int
	bar ()
	{
	  return -foo ();
	}

It generates:

		.file	"mvc5.c"
		.text
		.p2align 4,,15
		.globl	foo
		.type	foo, @function
	foo:
		movl	$10, %eax
		ret

		.type	foo.avx.2, @function
	foo.avx.2:
		movl	$10, %eax
		ret

		.type	foo.avx2.3, @function
	foo.avx2.3:
		movl	$10, %eax
		ret

		.weak	foo.resolver
		.type	foo.resolver, @function
	foo.resolver:
		subq	$8, %rsp
		call	__cpu_indicator_init
		movl	__cpu_model+12(%rip), %eax
		testb	$4, %ah
		je	.L8
		movl	$foo.avx2.3, %eax
		addq	$8, %rsp
		ret
	.L8:
		testb	$2, %ah
		movl	$foo.avx.2, %edx
		movl	$foo, %eax
		cmovne	%rdx, %rax
		addq	$8, %rsp
		ret

		.type	foo.ifunc, @gnu_indirect_function
		.set	foo.ifunc,foo.resolver

	// Note these functions are not referenced

		.type	bar.avx2.1, @function
	bar.avx2.1:
		subq	$8, %rsp
		xorl	%eax, %eax
		call	foo.ifunc
		addq	$8, %rsp
		negl	%eax
		ret

		.type	bar.avx.0, @function
	bar.avx.0:
		subq	$8, %rsp
		xorl	%eax, %eax
		call	foo.ifunc
		addq	$8, %rsp
		negl	%eax
		ret

		.type	bar, @function

	// Note how it calls foo.ifunc instead of foo.

	bar:
		subq	$8, %rsp
		xorl	%eax, %eax
		call	foo.ifunc
		addq	$8, %rsp
		negl	%eax
		ret


Now, if I remove the bar call, and just leave foo it generates:

		.type	foo, @function
	foo:
		movl	$10, %eax
		ret

		.type	foo.avx.0, @function
	foo.avx.0:
		movl	$10, %eax
		ret

		.type	foo.avx2.1, @function
	foo.avx2.1:
		movl	$10, %eax
		ret

Note, it does not generate the resolver at all.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797

  reply	other threads:[~2017-05-05 18:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 18:19 GCC target_clone support Michael Meissner
2017-05-05 18:45 ` Michael Meissner [this message]
     [not found]   ` <CAOvf_xzMMbbQ+adZ+hWYtxACn_6yS50nhhcVYeBuPnUKZNPc2g@mail.gmail.com>
2017-05-05 19:48     ` GCC target_clone support (functionality question) Michael Meissner
     [not found]       ` <CAOvf_xyeUdFnfXMszOb8ZcEava+pRmzTP2naErd5U8sr2E1xpw@mail.gmail.com>
2017-05-05 20:50         ` Michael Meissner
     [not found]   ` <87tw4y7adg.fsf@linaro.org>
2017-05-08 22:14     ` Jeff Law
2017-05-05 18:52 ` GCC target_clone support Michael Meissner
2017-05-05 20:17 ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170505184530.GA15560@ibm-tiger.the-meissners.org \
    --to=meissner@linux.vnet.ibm.com \
    --cc=Andreas.Krebbel@de.ibm.com \
    --cc=bschmidt@redhat.com \
    --cc=dje.gcc@gmail.com \
    --cc=evstupac@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hepenner@us.ibm.com \
    --cc=hubicka@ucw.cz \
    --cc=jakub@redhat.com \
    --cc=kirill.yukhin@gmail.com \
    --cc=law@redhat.com \
    --cc=marcus.shawcroft@arm.com \
    --cc=nickc@redhat.com \
    --cc=ramana.radhakrishnan@arm.com \
    --cc=rguenther@suse.de \
    --cc=richard.earnshaw@arm.com \
    --cc=rth@redhat.com \
    --cc=segher@kernel.crashing.org \
    --cc=ubizjak@gmail.com \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).