From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) by sourceware.org (Postfix) with ESMTPS id D3E323855020 for ; Mon, 26 Jul 2021 03:33:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D3E323855020 Received: by mail-vs1-xe32.google.com with SMTP id f28so4491936vsh.12 for ; Sun, 25 Jul 2021 20:33:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g3rm2D1gNggElRaE88zKo5p++o6as4IwKCHRxG2FQTU=; b=aIAHvWqnE+Mp7mRYQIC5SULYU+AabCTaDktVoi19ZbWQVoPd8UYN/HH1PmhmHxcdeG 0qpVJ/ctTcJxMKoXi1giGbZTUDcZtEthCqujhZRsnQ3z76AF298C7R3v8KXQmouZwQyB vMeeVjQNg96fqoUMSgf1G56oTbBOs0eivq7oX+IEetTY3i8g/3UOUG4aBLsI1CRgP88G FJPpTAYQFD2AR6LSgWl3SW5vljg8q13LzBcQAnxEXGnaQHHxRox6+0gZmu4oHUa5Z0oC yI1NC5qZFpqUpFq61PABydw6n8sdaZZcsG0bBLcxbR3qV73WLOOLRgdSruDAx0zr3aGz SrTg== X-Gm-Message-State: AOAM533HG7aTxHoMBSMcUvWUz/ycl0+zRnCZyNnLTE2lvE67wbZS0bhE j4se7au6a35UAVG12aSzwoupydO3qyq8EjNtxNI= X-Google-Smtp-Source: ABdhPJxeBfefKoCpX1V2TczBLjALfiPPZxFJLR6YL9Axrkw4T/wZm2yU+pQYeX+t6USl276QMDox/C3qsOJk0VIjAYU= X-Received: by 2002:a67:2d8b:: with SMTP id t133mr10527237vst.45.1627270429417; Sun, 25 Jul 2021 20:33:49 -0700 (PDT) MIME-Version: 1.0 References: <20210624121213.3469943-1-hjl.tools@gmail.com> In-Reply-To: From: Hongtao Liu Date: Mon, 26 Jul 2021 11:33:38 +0800 Message-ID: Subject: Re: PING^1 [PATCH v2] x86: Check AVX512 without mask instructions To: "H.J. Lu" Cc: Uros Bizjak , Hongtao Liu , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 03:33:54 -0000 On Wed, Jul 14, 2021 at 8:27 PM H.J. Lu wrote: > > On Fri, Jun 25, 2021 at 5:39 AM H.J. Lu wrote: > > > > On Fri, Jun 25, 2021 at 12:50 AM Uros Bizjak wrote: > > > > > > On Fri, Jun 25, 2021 at 4:51 AM Hongtao Liu wrote: > > > > > > > > On Fri, Jun 25, 2021 at 12:13 AM Uros Bizjak via Gcc-patches > > > > wrote: > > > > > > > > > > On Thu, Jun 24, 2021 at 2:12 PM H.J. Lu wrote: > > > > > > > > > > > > CPUID functions are used to detect CPU features. If vector ISAs > > > > > > are enabled, compiler is free to use them in these functions. Add > > > > > > __attribute__ ((target("general-regs-only"))) to CPUID functions > > > > > > to avoid vector instructions. > > > > > > > > > > These functions are intended to be inlined, so how does target > > > > > attribute affect inlining? > > > > I guess w/ -O0. they may not be inlined, that's why H.J adds those > > > > attributes to those functions. > > > > > > The problem is not with these functions, but with surrounding checks > > > for cpuid features. These checks are implemented with logic > > > instructions, and nothing prevents RA from allocating mask registers, > > > and consequently mask insn is emitted. Regarding mentioned functions, > > > cpuid insn pattern has four GPR single-reg constraints, so mask > > > registers can't be allocated here. > > > > > > > pr96814.dump: > > > > 0804aa40
: > > > > 804aa40: 8d 4c 24 04 lea 0x4(%esp),%ecx > > > > ... > > > > 804aa63: 6a 07 push $0x7 > > > > 804aa65: e8 e0 e7 ff ff call 804924a <__get_cpuid_count> > > > > > > > > Also we need to add a target attribute to avx512f_os_support (), and > > > > that would be enough to fix the AVX512 part. > > > > > > > > Moreover, all check functions in below files may also need to deal with: > > > > adx-check.h > > > > aes-avx-check.h > > > > aes-check.h > > > > amx-check.h > > > > attr-nocf-check-1a.c > > > > attr-nocf-check-3a.c > > > > avx2-check.h > > > > avx2-vpop-check.h > > > > avx512bw-check.h > > > > avx512-check.h > > > > avx512dq-check.h > > > > avx512er-check.h > > > > avx512f-check.h > > > > avx512vl-check.h > > > > avx-check.h > > > > bmi2-check.h > > > > bmi-check.h > > > > cf_check-1.c > > > > cf_check-2.c > > > > cf_check-3.c > > > > cf_check-4.c > > > > cf_check-5.c > > > > f16c-check.h > > > > fma4-check.h > > > > fma-check.h > > > > isa-check.h > > > > lzcnt-check.h > > > > m128-check.h > > > > m256-check.h > > > > m512-check.h > > > > mmx-3dnow-check.h > > > > mmx-check.h > > > > pclmul-avx-check.h > > > > pclmul-check.h > > > > pr39315-check.c > > > > rtm-check.h > > > > sha-check.h > > > > spellcheck-options-1.c > > > > spellcheck-options-2.c > > > > spellcheck-options-3.c > > > > spellcheck-options-4.c > > > > spellcheck-options-5.c > > > > sse2-check.h > > > > sse3-check.h > > > > sse4_1-check.h > > > > sse4_2-check.h > > > > sse4a-check.h > > > > sse-check.h > > > > ssse3-check.h > > > > stack-check-11.c > > > > stack-check-12.c > > > > stack-check-17.c > > > > stack-check-18.c > > > > stack-check-19.c > > > > xop-check.h > > > > > > True, but this would just paper over the real problem. Now, it is > > > expected that the user decorates the function that checks CPUID > > > features with the target attribute. I'm not sure if this is OK. vmovw is enabled by AVX512FP16, and compile cpuid check function w/ avx512fp16 may result in SIGILL on non-avx512fp16 target(though, we didn't get a testcase yet). Would that be a sufficient reason to disable avx512 for cpuid check? > > > > > > Uros. > > > > CPUID functions are used to detect CPU features. If mask instructions > > are enabled, compiler is free to use them in these functions. Disable > > AVX512F in AVX512 check with target pragma to avoid mask instructions. > > > > OK for master? > > > > PING: > > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573717.html > > > -- > H.J. -- BR, Hongtao