From: Jason Merrill <jason@redhat.com>
To: Sriraman Tallam <tmsriram@google.com>
Cc: Xinliang David Li <davidxl@google.com>,
mark@codesourcery.com, nathan@codesourcery.com,
"H.J. Lu" <hjl.tools@gmail.com>,
Richard Guenther <richard.guenther@gmail.com>,
Jan Hubicka <jh@suse.cz>, Uros Bizjak <ubizjak@gmail.com>,
reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org
Subject: Re: User directed Function Multiversioning via Function Overloading (issue5752064)
Date: Fri, 05 Oct 2012 18:32:00 -0000 [thread overview]
Message-ID: <506F27AF.3070805@redhat.com> (raw)
In-Reply-To: <CAAs8HmyKPG_LxxxP2ngkGTFAKUPXQDJsbbsrOB_oAP0ViyER3g@mail.gmail.com>
On 08/24/2012 08:34 PM, Sriraman Tallam wrote:
> + /* For function versions, their parms and types match
> + but they are not duplicates. Record function versions
> + as and when they are found. */
> + if (TREE_CODE (fn) == FUNCTION_DECL
> + && TREE_CODE (method) == FUNCTION_DECL
> + && (DECL_FUNCTION_SPECIFIC_TARGET (fn)
> + || DECL_FUNCTION_SPECIFIC_TARGET (method))
> + && targetm.target_option.function_versions (fn, method))
> + {
> + targetm.set_version_assembler_name (fn);
> + targetm.set_version_assembler_name (method);
> + continue;
> + }
This seems like an odd place to be setting assembler names; better to
just have the existing mangle_decl_assembler_name hook add the
appropriate suffix when it's called normally.
> + Also, mark this function as needed if it is marked inline but
> + is a multi-versioned function. */
Why? If it's used, it should be marked needed though the normal process.
> + error_at (location_of (DECL_NAME (OVL_CURRENT (fn))),
> + "Call to multiversioned function %<%D(%A)%> with"
> + " no default version", DECL_NAME (OVL_CURRENT (fn)),
> + build_tree_list_vec (*args));
location_of just returns input_location if you ask it for the location
of an identifier, so you might as well use error with no explicit
location. And why not print candidates->fn instead of pasting the
name/args? Also, lowercase "call".
> + {
> + tree dispatcher_decl = NULL;
> + struct cgraph_node *node = cgraph_get_node (fn);
> + if (node != NULL)
> + dispatcher_decl = cgraph_get_node (fn)->version_dispatcher_decl;
> + if (dispatcher_decl == NULL)
> + {
> + error_at (input_location, "Call to multiversioned function"
> + " without a default is not allowed");
> + return NULL;
> + }
> + retrofit_lang_decl (dispatcher_decl);
> + gcc_assert (dispatcher_decl != NULL);
> + fn = dispatcher_decl;
> + }
Let's move this logic into a separate function that returns the
dispatcher function.
> + /* Both functions must be marked versioned. */
> + gcc_assert (DECL_FUNCTION_VERSIONED (cand1->fn)
> + && DECL_FUNCTION_VERSIONED (cand2->fn));
Why can't you compare a versioned function and a non-versioned one?
The code in joust should go further down in the function, before the
handling of two declarations of the same function.
> + /* For multiversioned functions, aggregate all the versions here for
> + generating the dispatcher body later if necessary. */
> +
> + if (TREE_CODE (candidates->fn) == FUNCTION_DECL
> + && DECL_FUNCTION_VERSIONED (candidates->fn))
> + {
> + VEC (tree, heap) *fn_ver_vec = NULL;
> + struct z_candidate *ver = candidates;
> + fn_ver_vec = VEC_alloc (tree, heap, 2);
> + for (;ver; ver = ver->next)
> + VEC_safe_push (tree, heap, fn_ver_vec, ver->fn);
> + gcc_assert (targetm.get_function_versions_dispatcher);
> + targetm.get_function_versions_dispatcher (fn_ver_vec);
> + VEC_free (tree, heap, fn_ver_vec);
> + }
This seems to assume that all the functions in the list of candidates
are versioned, but there might be unrelated functions from different
namespaces. Also, doing this every time someone calls a versioned
function seems like the wrong place; I would think it would be better to
build up a list of versions as you seed declarations, and then use that
list to define the dispatcher at EOF if it's needed.
> + if (TREE_CODE (decl) == FUNCTION_DECL
> + && DECL_FUNCTION_VERSIONED (decl)
> + && DECL_ASSEMBLER_NAME_SET_P (decl))
> + write_source_name (DECL_ASSEMBLER_NAME (decl));
> + else
> + write_source_name (DECL_NAME (decl));
Again, I think it's better to handle the suffix via
mangle_decl_assembler_name.
Jason
next prev parent reply other threads:[~2012-10-05 18:32 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 0:47 Sriraman Tallam
2012-03-07 14:05 ` Richard Guenther
2012-03-07 19:08 ` Sriraman Tallam
2012-03-08 21:37 ` Xinliang David Li
2012-03-08 21:00 ` Xinliang David Li
2012-03-09 20:04 ` Sriraman Tallam
2012-04-27 5:09 ` Sriraman Tallam
2012-04-27 13:39 ` H.J. Lu
2012-04-27 14:35 ` Sriraman Tallam
2012-04-27 14:39 ` H.J. Lu
2012-04-27 14:53 ` Sriraman Tallam
2012-04-27 15:36 ` H.J. Lu
2012-04-27 15:45 ` Sriraman Tallam
2012-05-01 23:51 ` Sriraman Tallam
2012-05-02 0:09 ` H.J. Lu
2012-05-02 2:45 ` Sriraman Tallam
2012-05-02 13:42 ` H.J. Lu
2012-05-02 15:08 ` Sriraman Tallam
2012-05-02 16:06 ` H.J. Lu
2012-05-02 17:44 ` Sriraman Tallam
2012-05-02 18:04 ` H.J. Lu
2012-05-07 16:58 ` Sriraman Tallam
2012-05-09 19:01 ` Sriraman Tallam
2012-05-10 17:55 ` H.J. Lu
2012-05-12 2:04 ` Sriraman Tallam
2012-05-12 13:38 ` H.J. Lu
2012-05-14 18:29 ` Sriraman Tallam
2012-05-26 0:07 ` H.J. Lu
2012-05-26 0:16 ` Sriraman Tallam
2012-05-26 0:27 ` H.J. Lu
2012-05-26 1:54 ` Sriraman Tallam
[not found] ` <CAMe9rOowm9K7r1xnRdRjW5Y4Ay+WxgSsBLTgGvq24z=i42AS+g@mail.gmail.com>
[not found] ` <CAAs8HmzeQigcLQyfkC02u=6gCTLkjLLa_jYmp+b1HEtpMCrYWw@mail.gmail.com>
2012-05-26 5:06 ` H.J. Lu
2012-05-26 22:35 ` Sriraman Tallam
2012-05-26 23:56 ` H.J. Lu
2012-05-27 0:24 ` Sriraman Tallam
2012-05-27 2:06 ` H.J. Lu
2012-05-27 2:23 ` Sriraman Tallam
2012-05-27 2:31 ` H.J. Lu
2012-05-27 19:02 ` Ian Lance Taylor
2012-06-04 19:01 ` Sriraman Tallam
2012-06-04 21:36 ` H.J. Lu
2012-06-04 22:29 ` Sriraman Tallam
2012-06-05 13:56 ` H.J. Lu
2012-06-14 20:35 ` Sriraman Tallam
2012-06-20 1:10 ` Sriraman Tallam
2012-07-06 9:14 ` Richard Guenther
2012-07-06 17:38 ` Sriraman Tallam
2012-07-07 6:06 ` Jason Merrill
2012-07-07 18:38 ` Xinliang David Li
2012-07-08 11:21 ` Jason Merrill
2012-07-09 21:27 ` Xinliang David Li
2012-07-10 9:46 ` Jason Merrill
2012-07-10 16:09 ` Xinliang David Li
[not found] ` <CAAs8HmxHF38ktt6syjWp-MpjiX+6NcXh7_8Xn6iKnAiF2vRymQ@mail.gmail.com>
2012-07-19 20:40 ` Jason Merrill
2012-07-30 19:16 ` Sriraman Tallam
2012-08-25 0:34 ` Sriraman Tallam
2012-09-18 16:29 ` Sriraman Tallam
2012-10-05 17:07 ` Xinliang David Li
2012-10-05 17:44 ` Jason Merrill
2012-10-05 18:14 ` Jason Merrill
2012-10-05 21:58 ` Sriraman Tallam
2012-10-05 22:50 ` Jason Merrill
2012-10-05 23:45 ` Sriraman Tallam
2012-10-05 18:32 ` Jason Merrill [this message]
2012-10-11 0:13 ` Sriraman Tallam
2012-10-12 22:41 ` Sriraman Tallam
2012-10-19 15:23 ` Diego Novillo
2012-10-20 4:29 ` Sriraman Tallam
2012-10-23 21:21 ` Sriraman Tallam
2012-10-26 16:53 ` Jan Hubicka
2012-10-28 4:31 ` Sriraman Tallam
2012-10-29 13:05 ` Jan Hubicka
2012-10-29 17:56 ` Sriraman Tallam
2012-10-30 19:18 ` Jason Merrill
2012-10-31 0:58 ` Sriraman Tallam
[not found] ` <CAAs8Hmw09giv-5_v0irhByTjTJV=kD58rCAD2SAz7M8zrwjBOA@mail.gmail.com>
2012-10-31 14:27 ` Jason Merrill
2012-11-02 2:53 ` Sriraman Tallam
2012-11-06 2:38 ` Sriraman Tallam
2012-11-06 15:52 ` Jason Merrill
2012-11-06 18:17 ` Sriraman Tallam
2012-11-10 1:33 ` Sriraman Tallam
2012-11-12 5:04 ` Jason Merrill
2012-11-13 1:11 ` Sriraman Tallam
2012-11-13 2:39 ` Jason Merrill
2012-11-13 21:57 ` Sriraman Tallam
2012-11-17 22:23 ` H.J. Lu
2012-11-06 22:15 ` Gerald Pfeifer
2012-10-26 14:11 ` Diego Novillo
2012-10-26 16:54 Xinliang David Li
2012-10-26 17:28 ` Sriraman Tallam
2012-11-06 22:17 Dominique Dhumieres
2012-11-07 1:16 ` Gerald Pfeifer
2012-11-07 8:53 ` Dominique Dhumieres
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=506F27AF.3070805@redhat.com \
--to=jason@redhat.com \
--cc=davidxl@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=jh@suse.cz \
--cc=mark@codesourcery.com \
--cc=nathan@codesourcery.com \
--cc=reply@codereview.appspotmail.com \
--cc=richard.guenther@gmail.com \
--cc=tmsriram@google.com \
--cc=ubizjak@gmail.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).