From: Bill Schmidt <wschmidt@linux.ibm.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
David Edelsohn <dje.gcc@gmail.com>,
bergner@linux.ibm.com, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] rs6000: Remove builtin mask check from builtin_decl [PR102347]
Date: Wed, 29 Sep 2021 06:59:00 -0500 [thread overview]
Message-ID: <10dc76e1-cf19-acc4-bb43-871ea87d3363@linux.ibm.com> (raw)
In-Reply-To: <62e6c096-f4a0-dc25-edba-ba0f32179438@linux.ibm.com>
Hi Kewen,
On 9/28/21 9:34 PM, Kewen.Lin wrote:
> Hi Bill,
>
> Thanks for your prompt comments!
>
> on 2021/9/29 上午3:24, Bill Schmidt wrote:
>> Hi Kewen,
>>
>> Although I agree that what we do now is tragically bad (and will be fixed in the builtin rewrite), this seems a little too cavalier to remove all checking during initialization without adding any checking somewhere else. :-) We still need to check for invalid usage when the builtin is expanded, and I don't think the old code does this at all.
>>
> If I read the code right, there are some following places to check the invalid usage or not.
> 1) for folding, rs6000_gimple_fold_builtin -> rs6000_builtin_is_supported_p -> check mask
> -> defer to expand if invalid.
> 2) for expanding, obtain func_valid_p, error in rs6000_invalid_builtin.
>
> Both places seem to exist before the builtin rewrite, am I missing something?
>
> btw, I remembered I used one built gcc with my fix to compile one test case which is supposed to fail
> due to its invalid usage builtin at option -flto, it failed (errored) as expected but at LTRANS phase
> since it's the time to do expansion for no-fat-objs scenario.
OK. If you are comfortable that this will be caught when the builtin is actually not valid, then I'll
withdraw my objection. Can you test it? I know that we've been trying to fix these cases piecemeal
in the old support, and as Peter says it's important to backport this, we need the solution. I just
want to be sure we're not breaking something, and test coverage in this area is pretty terrible.
Thanks!
Bill
>
>> Unless you are planning to do a backport, I think the proper way forward here is to just wait for the new builtin support to land. In the new code, we initialize all built-ins up front, and check properly at expansion time whether the builtin is enabled in the environment that obtains during expand.
> Good to know that! Nice! btw, for this issue itself, the current implementation (without rewriting)
> also initializes the built-ins in the table since MMA built-ins guarded in TARGET_EXTRA_BUILTINS,
> the root cause is the rs6000_builtin_mask can't set up (be switched) expectedly since the checking
> time is too early right when the built-in function_decl being created.
>
> BR,
> Kewen
>
>> My two cents,
>> Bill
>>
>> On 9/28/21 3:13 AM, Kewen.Lin wrote:
>>> Hi,
>>>
>>> As the discussion in PR102347, currently builtin_decl is invoked so
>>> early, it's when making up the function_decl for builtin functions,
>>> at that time the rs6000_builtin_mask could be wrong for those
>>> builtins sitting in #pragma/attribute target functions, though it
>>> will be updated properly later when LTO processes all nodes.
>>>
>>> This patch is to align with the practice i386 port adopts, also
>>> align with r10-7462 by relaxing builtin mask checking in some places.
>>>
>>> Bootstrapped and regress-tested on powerpc64le-linux-gnu P9 and
>>> powerpc64-linux-gnu P8.
>>>
>>> Is it ok for trunk?
>>>
>>> BR,
>>> Kewen
>>> -----
>>> gcc/ChangeLog:
>>>
>>> PR target/102347
>>> * config/rs6000/rs6000-call.c (rs6000_builtin_decl): Remove builtin
>>> mask check.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR target/102347
>>> * gcc.target/powerpc/pr102347.c: New test.
>>>
>>> ---
>>> gcc/config/rs6000/rs6000-call.c | 14 ++++----------
>>> gcc/testsuite/gcc.target/powerpc/pr102347.c | 15 +++++++++++++++
>>> 2 files changed, 19 insertions(+), 10 deletions(-)
>>> create mode 100644 gcc/testsuite/gcc.target/powerpc/pr102347.c
>>>
>>> diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
>>> index fd7f24da818..15e0e09c07d 100644
>>> --- a/gcc/config/rs6000/rs6000-call.c
>>> +++ b/gcc/config/rs6000/rs6000-call.c
>>> @@ -13775,23 +13775,17 @@ rs6000_init_builtins (void)
>>> }
>>> }
>>>
>>> -/* Returns the rs6000 builtin decl for CODE. */
>>> +/* Returns the rs6000 builtin decl for CODE. Note that we don't check
>>> + the builtin mask here since there could be some #pragma/attribute
>>> + target functions and the rs6000_builtin_mask could be wrong when
>>> + this checking happens, though it will be updated properly later. */
>>>
>>> tree
>>> rs6000_builtin_decl (unsigned code, bool initialize_p ATTRIBUTE_UNUSED)
>>> {
>>> - HOST_WIDE_INT fnmask;
>>> -
>>> if (code >= RS6000_BUILTIN_COUNT)
>>> return error_mark_node;
>>>
>>> - fnmask = rs6000_builtin_info[code].mask;
>>> - if ((fnmask & rs6000_builtin_mask) != fnmask)
>>> - {
>>> - rs6000_invalid_builtin ((enum rs6000_builtins)code);
>>> - return error_mark_node;
>>> - }
>>> -
>>> return rs6000_builtin_decls[code];
>>> }
>>>
>>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr102347.c b/gcc/testsuite/gcc.target/powerpc/pr102347.c
>>> new file mode 100644
>>> index 00000000000..05c439a8dac
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/powerpc/pr102347.c
>>> @@ -0,0 +1,15 @@
>>> +/* { dg-do link } */
>>> +/* { dg-require-effective-target power10_ok } */
>>> +/* { dg-require-effective-target lto } */
>>> +/* { dg-options "-flto -mdejagnu-cpu=power9" } */
>>> +
>>> +/* Verify there are no error messages in LTO mode. */
>>> +
>>> +#pragma GCC target "cpu=power10"
>>> +int main ()
>>> +{
>>> + float *b;
>>> + __vector_quad c;
>>> + __builtin_mma_disassemble_acc (b, &c);
>>> + return 0;
>>> +}
>>> --
>>> 2.27.0
>>>
>
next prev parent reply other threads:[~2021-09-29 11:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-28 8:13 Kewen.Lin
2021-09-28 19:24 ` Bill Schmidt
2021-09-29 0:25 ` Peter Bergner
2021-09-29 2:34 ` Kewen.Lin
2021-09-29 11:59 ` Bill Schmidt [this message]
2021-09-30 3:06 ` Kewen.Lin
2021-09-30 22:13 ` Segher Boessenkool
2021-10-11 6:30 ` Kewen.Lin
2021-10-12 16:36 ` Bill Schmidt
2021-10-13 3:25 ` Kewen.Lin
2021-11-30 0:07 ` Segher Boessenkool
2021-10-20 9:35 ` PING^1 " Kewen.Lin
2021-11-04 10:58 ` PING^2 " Kewen.Lin
2021-11-22 2:25 ` PING^3 " Kewen.Lin
2021-11-30 0:16 ` Segher Boessenkool
2021-11-30 4:54 ` Kewen.Lin
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=10dc76e1-cf19-acc4-bb43-871ea87d3363@linux.ibm.com \
--to=wschmidt@linux.ibm.com \
--cc=bergner@linux.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linkw@linux.ibm.com \
--cc=segher@kernel.crashing.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).