From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id C53BF3858D39 for ; Wed, 22 Sep 2021 14:21:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C53BF3858D39 Received: by mail-ot1-x32e.google.com with SMTP id l7-20020a0568302b0700b0051c0181deebso3598543otv.12 for ; Wed, 22 Sep 2021 07:21:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qIbZoMeHLxBKyW8FXzuWMP2DpdojYmfNeIdCSUo/+oA=; b=XjG2azvU7RsLJwhV67Y+4mMrIm5IdHnIcpJZ8VOTfyWdYCJZ0bcZ5RxMlK6JZetJTK p/WWhgkj5ErpgLQYbbWAqGDtjznPbCdvVt1JsWK3Utdk9dXnNS3HXa+qjK2nqJdcQoQZ nVH/H+5cHxk20Bh15Zawv7x++zemJ9V+WKGTdggdT1u9UgwHvYDWGiltewHcWtNOya17 d0YIh4mmnXeOf0Anl4ZZbFTuU/ZnTN8bwdV7HKJksXpEWgK5p3jrt8EywrKQ8tkJPJ9F EuFgKsTxsTVRVKamH7v2xOzd/EVJDc9kuSbG9pqM9cm6P3H8W8fxGfRyUboCHeU/6JlK mJhg== X-Gm-Message-State: AOAM531kGiTYicDsFwdhBT5hpF/xe9+KTFrltJrKVpxGyXq9yueVgiZN YAOHIPvhe69YuH2gRRLHqOU= X-Google-Smtp-Source: ABdhPJxVQh3NJNcjj31LhaRvh6XPIteuZGdGN5MsaultmDSKbmHKrjSuPeH374QZy88+rfBTH5it3w== X-Received: by 2002:a9d:4104:: with SMTP id o4mr7300ote.251.1632320466990; Wed, 22 Sep 2021 07:21:06 -0700 (PDT) Received: from [192.168.0.41] (97-118-96-133.hlrn.qwest.net. [97.118.96.133]) by smtp.gmail.com with ESMTPSA id q7sm501458otl.68.2021.09.22.07.21.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Sep 2021 07:21:06 -0700 (PDT) Subject: Re: [PATCH] Enable auto-vectorization at O2 with very-cheap cost model. To: Hongtao Liu Cc: Richard Biener , Jakub Jelinek , Florian Weimer , Segher Boessenkool , Richard Sandiford , Premachandra.Mallappa@amd.com, GCC Patches , Bill Schmidt , liuhongt , Joseph Myers References: <20210916043305.1674303-1-hongtao.liu@intel.com> <4fe85f3d-b4fd-4419-04f0-c645e23e778d@gmail.com> From: Martin Sebor Message-ID: <5703bdb6-dc01-4436-2403-35832619ebb4@gmail.com> Date: Wed, 22 Sep 2021 08:21:05 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, NICE_REPLY_A, 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: Wed, 22 Sep 2021 14:21:09 -0000 On 9/21/21 7:38 PM, Hongtao Liu wrote: > On Mon, Sep 20, 2021 at 4:13 AM Martin Sebor wrote: ... >>>>> diff --git a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c >>>>> index 1d79930cd58..9351f7e7a1a 100644 >>>>> --- a/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c >>>>> +++ b/gcc/testsuite/c-c++-common/Wstringop-overflow-2.c >>>>> @@ -1,7 +1,7 @@ >>>>> /* PR middle-end/91458 - inconsistent warning for writing past the end >>>>> of an array member >>>>> { dg-do compile } >>>>> - { dg-options "-O2 -Wall -Wno-array-bounds -fno-ipa-icf" } */ >>>>> + { dg-options "-O2 -Wall -Wno-array-bounds -fno-ipa-icf -fno-tree-vectorize" } */ >>>> >>>> The testcase is large - what part requires this change? Given the >>>> testcase was added for inconsistent warnings do they now become >>>> inconsistent again as we enable vectorization at -O2? >>>> >>>> That said, the testcase adjustments need some explaining - I suppose >>>> you didn't just slap -fno-tree-vectorize to all of those changing >>>> behavior? >>>> >>> void ga1_ (void) >>> { >>> a1_.a[0] = 0; >>> a1_.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" } >>> a1_.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" } >>> >>> struct A1 a; >>> a.a[0] = 0; >>> a.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" } >>> a.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" } >>> sink (&a); >>> } >>> >>> It's supposed to be 2 warning for a.a[1] = 1 and a.a[2] = 1 since >>> there are 2 accesses, but after enabling vectorization, there's only >>> one access, so one warning is missing which causes the failure. With the stores vectorized, is the warning on the correct line or does it point to the first store, the one that's in bounds, as it does with -O3? The latter would be a regression at -O2. >> >> I would find it preferable to change the test code over disabling >> optimizations that are on by default. My concern is that the test >> would no longer exercise the default behavior. (The same goes for >> the -fno-ipa-icf option.) > Hmm, it's a middle-end test, for some backend, it may not do > vectorization(it depends on TARGET_VECTOR_MODE_SUPPORTED_P and > relative cost model). Yes, there are quite a few warning tests like that. Their main purpose is to verify that in common GCC invocations (i.e., without any special options) warnings are a) issued when expected and b) not issued when not expected. Otherwise, middle end warnings are known to have both false positives and false negatives in some invocations, depending on what optimizations are in effect. Indiscriminately disabling common optimizations for these large tests and invoking them under artificial conditions would compromise this goal and hide the problems. If enabling vectorization at -O2 causes regressions in the quality of diagnostics (as the test failure above indicates seems to be happening) we should investigate these and open bugs for them so they can be fixed. We can then tweak the specific failing test cases to avoid the failures until they are fixed. Martin