public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO
Date: Thu, 23 Sep 2021 06:51:33 +0000	[thread overview]
Message-ID: <bug-102347-4-2CtlXnvabT@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102347-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktkachov at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

--- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #6)
> Quickly looking at the rs6000 code, it fails here:
> 
> #1  0x0000000011a0993c in rs6000_invalid_builtin
> (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
> ../../gcc/config/rs6000/rs6000-call.c:11643
> #2  0x0000000011a13134 in rs6000_builtin_decl (code=1603, initialize_p=true)
> at ../../gcc/config/rs6000/rs6000-call.c:13870
> #3  0x00000000115c3900 in unpack_ts_function_decl_value_fields
> (bp=0x3fffffffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
> #4  0x00000000115c4790 in streamer_read_tree_bitfields (ib=0x3fffffffe6a0,
> data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
> #5  0x0000000010deaa28 in lto_read_tree_1 (ib=0x3fffffffe6a0,
> data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697
> 
> which relies on rs6000_builtin_mask. Note the mask is set here:
> rs6000_builtin_mask = rs6000_builtin_mask_calculate ();
> 
> where rs6000_builtin_mask_calculate is based on TARGET_* values.
> 
> I think the mask check should be deferred later as it should be based on
> proper
> target_node that is set via rs6000_set_current_function. It should not check
> it in lto_read_tree_1.

Thanks for looking into this, Martin! I tried to investigate if we can set
target_option_node as the appropriate fndecl when doing the check, then both
rs6000 and aarch64 ports don't need to change the hook since both of them
respect target_option_node switches well.

We have streamed out those fndecls with their target_option_nodes (if they
have)
into the .gnu.lto_.decls.xxx, fndecls are built well after reading, for one
bif fndecl, if we know which function it exists in, we can set_current_function
to the corresponding fndecl when checking the bif. After some hackings, I
noticed that there are two difficulties:
  1) For one bif, we need a way to know which fndecls use it. Now there seems
no
     information easy for this right before checking the bif?
  2) One bif can sit in several functions which probably have different
     target_option_nodes, we have to iterate all of them. This seems artificial
     just for this need.

I might still miss something, but after the hacking I agree to update the
target hooks is better. For rs6000, the mask checking removal aligns with the
way that i386 uses and also some changes like r10-7462 by neglecting mask.
Later rs6000_expand_builtin will still do the check with mask. But the erroring
would be in LTRANS, WPA phase won't emit error then. Is it one concern? If so,
which place can we delay this check to?

For aarch64 port, it seems to need some more adjustments?

  parent reply	other threads:[~2021-09-23  6:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 12:18 [Bug lto/102347] New: " chip.kerchner at ibm dot com
2021-09-15 13:20 ` [Bug lto/102347] " linkw at gcc dot gnu.org
2021-09-15 13:36 ` [Bug target/102347] " rguenth at gcc dot gnu.org
2021-09-16 10:36 ` linkw at gcc dot gnu.org
2021-09-17  9:10 ` linkw at gcc dot gnu.org
2021-09-17  9:20 ` pinskia at gcc dot gnu.org
2021-09-17 14:15 ` marxin at gcc dot gnu.org
2021-09-21 23:53 ` bergner at gcc dot gnu.org
2021-09-23  6:51 ` linkw at gcc dot gnu.org [this message]
2021-09-23  7:08 ` linkw at gcc dot gnu.org
2021-09-23  7:26 ` rguenther at suse dot de
2021-11-26  1:59 ` linkw at gcc dot gnu.org
2021-11-30  4:51 ` cvs-commit at gcc dot gnu.org
2021-12-01 18:17 ` cvs-commit at gcc dot gnu.org
2021-12-10 13:31 ` wschmidt at gcc dot gnu.org
2021-12-15  5:48 ` cvs-commit at gcc dot gnu.org
2021-12-15  6:15 ` cvs-commit at gcc dot gnu.org
2021-12-15  8:05 ` cvs-commit at gcc dot gnu.org
2021-12-15  8:13 ` linkw at gcc dot gnu.org
2021-12-15  8:25 ` linkw at gcc dot gnu.org

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=bug-102347-4-2CtlXnvabT@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).