From: David Malcolm <dmalcolm@redhat.com>
To: Andrea Corallo <andrea.corallo@arm.com>,
David Malcolm via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: jit@gcc.gnu.org, nd@arm.com
Subject: Re: [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126]
Date: Fri, 19 Feb 2021 16:13:50 -0500 [thread overview]
Message-ID: <71b1c0e3405fbb537ee925dcab68cafebd32fc9d.camel@redhat.com> (raw)
In-Reply-To: <gkrczwwweec.fsf@arm.com>
On Fri, 2021-02-19 at 11:16 +0100, Andrea Corallo wrote:
> David Malcolm via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>
> > I tried several approaches to fixing this; this seemed the
> > least invasive.
>
> Hi Dave,
>
> thanks for fixing this.
>
> I do have a trivial question: are we guaranteed that the middle-end
> will
> not try to add any build-in other than a trap?
No; the middle-end can add various other builtins.
The C/C++ FE have c_define_builtins, which calls def_builtin_1 on
everything with DEF_BUILTIN, then calls:
targetm.init_builtins ();
build_common_builtin_nodes ();
jit_langhook_init calls build_common_builtin_nodes.
The jit builtins_manager creates recording::functions (and their
supporting types) for any builtins that are explicitly used, and these
recording::functions get turned into trees during playback.
I looked at the doing the equivalent of DEF_BUILTIN for any builtins
that haven't been created yet, but when to do it?
(a) in the builtin manager... but not all builtin-types are supported
yet (e.g. BT_FLOAT16), so it would be a big patch to do it that way
(b) in jit_langhook_init... but then if the user creates a builtin that
wasn't referenced before in a 2nd in-memory compile, I think the types
can get out-of-sync.
So I went with the patch I did as it seems to be the least invasive way
of fixing the specific problem.
Dave
prev parent reply other threads:[~2021-02-19 21:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 2:31 David Malcolm
2021-02-19 10:16 ` Andrea Corallo
2021-02-19 10:32 ` Andrea Corallo
2021-02-19 21:13 ` David Malcolm [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=71b1c0e3405fbb537ee925dcab68cafebd32fc9d.camel@redhat.com \
--to=dmalcolm@redhat.com \
--cc=andrea.corallo@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jit@gcc.gnu.org \
--cc=nd@arm.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).