From: Jeff Law <jeffreyalaw@gmail.com>
To: "Christoph Müllner" <christoph.muellner@vrull.eu>,
"Richard Biener" <richard.guenther@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Manolis Tsamis <manolis.tsamis@vrull.eu>,
Martin Jambor <mjambor@suse.cz>, Jan Hubicka <jh@suse.cz>,
Philipp Tomsich <philipp.tomsich@vrull.eu>
Subject: Re: [RFC PATCH] ipa-guarded-deref: Add new pass to dereference function pointers
Date: Tue, 15 Nov 2022 09:33:11 -0700 [thread overview]
Message-ID: <2794ca17-a334-7d4e-225f-1b1754578638@gmail.com> (raw)
In-Reply-To: <CAEg0e7gdRHk-we0rspapGyD8_wnyuyGkyxzue=YQPHFJ0DwPCA@mail.gmail.com>
On 11/14/22 08:38, Christoph Müllner wrote:
>
> Ok, I will add the check.
>
> Still, I don't think that the optimization changes the behavior in the
> case of different ABIs
> (i.e. the situation is problematic regardless if there is an indirect call
> or a guarded direct call).
> What could be done additionally to dropping the candidate is to emit a
> warning (similar like ipa-devirt does for ODR violations).
The one target I'm aware of where this is most likely to cause problems
would be the older 32bit PA SOM ABI. It has the property that the ABI
uses different registers for parameter passing for direct vs indirect
calls. But with all this happening before RTL generation we should be
fine, even for that ABI (and its generally safe in that ABI to change an
indirect to a direct call, but not vice-versa).
Jeff
prev parent reply other threads:[~2022-11-15 16:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-13 15:09 Christoph Muellner
2022-11-14 7:30 ` Richard Biener
2022-11-14 8:13 ` Christoph Müllner
2022-11-14 9:00 ` Richard Biener
2022-11-14 9:31 ` Christoph Müllner
2022-11-14 10:10 ` Richard Biener
2022-11-14 11:46 ` Christoph Müllner
2022-11-14 13:48 ` Richard Biener
2022-11-14 15:38 ` Christoph Müllner
2022-11-15 16:33 ` Jeff Law [this message]
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=2794ca17-a334-7d4e-225f-1b1754578638@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=christoph.muellner@vrull.eu \
--cc=gcc-patches@gcc.gnu.org \
--cc=jh@suse.cz \
--cc=manolis.tsamis@vrull.eu \
--cc=mjambor@suse.cz \
--cc=philipp.tomsich@vrull.eu \
--cc=richard.guenther@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).