public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Hongtao Liu <crazylht@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Kirill Yukhin <kirill.yukhin@gmail.com>,
	Hongtao Liu <hongtao.liu@intel.com>
Subject: Re: [PATCH v3] x86: make VPTERNLOG* usable on less than 512-bit operands with just AVX512F
Date: Tue, 4 Jul 2023 17:29:36 +0200	[thread overview]
Message-ID: <ec236a63-7ce3-1828-d7f3-5d4a793d9365@suse.com> (raw)
In-Reply-To: <CAMZc-bxaFtCVoKZLq51WzfO1=WZUHqTGpytYerKERbnjjL8jfQ@mail.gmail.com>

On 27.06.2023 07:11, Hongtao Liu wrote:
> On Tue, Jun 20, 2023 at 5:34 PM Hongtao Liu <crazylht@gmail.com> wrote:
>>
>> On Tue, Jun 20, 2023 at 5:03 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>
>>> On 20.06.2023 10:33, Hongtao Liu wrote:
>>>> On Tue, Jun 20, 2023 at 3:07 PM Jan Beulich via Gcc-patches
>>>> <gcc-patches@gcc.gnu.org> wrote:
>>>>>
>>>>> I guess the underlying pattern, going along the lines of what
>>>>> <mask_codefor>one_cmpl<mode>2<mask_name> uses, can be applied elsewhere
>>>>> as well.
>>>> That should be guarded with !TARGET_PREFER_AVX256, let's handle that
>>>> in a separate patch.
>>>
>>> Sure, and as indicated there are more places where similar things could
>>> be done.
>>>
>>>>> --- /dev/null
>>>>> +++ b/gcc/testsuite/gcc.target/i386/avx512f-copysign.c
>>>>> @@ -0,0 +1,32 @@
>>>>> +/* { dg-do compile } */
>>>>> +/* { dg-options "-mavx512f -mno-avx512vl -O2" } */
>>>> Please explicitly add -mprefer-vector-width=512, our tester will also
>>>> test unix{-m32 \-march=cascadelake,\ -march=cascadelake} which set the
>>>> - mprefer-vector-width=256, -mprefer-vector-width=512 in dg-options
>>>> can overwrite that.
>>>
>>> Oh, I see. Will do. And I expect I then also need to adjust the newly
>>> added avx512f-dupv2di.c from the earlier patch. I guess I could commit
>>> that option addition there as obvious?
>> Still need to send out the patch, and commit as an obvious fix.
>>>
>>>> Others LGTM.
>>>
>>> May I take this as "okay with that change", or should I submit v4?
>> Okay. no need for a v4 version.
>>>
> avx512f-copysign.c failed for -m32, we need to add -mfpmath=sse to dg-options.

Oh, of course. I will take care of this, but it may take me a couple of
days, as I just came back from a week of vacation. One question though:
Elsewhere such tests are simply suppressed for 32-bit. Personally I'd
prefer going that route, but if you think adding -mfpmath=sse is indeed
better, I'll follow your request.

Jan

  reply	other threads:[~2023-07-04 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20  7:06 Jan Beulich
2023-06-20  8:33 ` Hongtao Liu
2023-06-20  9:03   ` Jan Beulich
2023-06-20  9:34     ` Hongtao Liu
2023-06-27  5:11       ` Hongtao Liu
2023-07-04 15:29         ` Jan Beulich [this message]
2023-07-05  1:15           ` Liu, Hongtao

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=ec236a63-7ce3-1828-d7f3-5d4a793d9365@suse.com \
    --to=jbeulich@suse.com \
    --cc=crazylht@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hongtao.liu@intel.com \
    --cc=kirill.yukhin@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).