From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by sourceware.org (Postfix) with ESMTPS id 4DD7F385702C for ; Tue, 13 Apr 2021 15:01:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4DD7F385702C Received: by mail-qk1-x72f.google.com with SMTP id x11so18079058qkp.11 for ; Tue, 13 Apr 2021 08:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=+Rd2LONp/24/Zsfbd1rP8cDjpq5GXBwXqkIBzLhcmes=; b=NW2LBmyflnRt6VpisBGKGqe69PA6bzh1M/jMxF2z+2luGIk8V/o4DPJWHHGv08vDKa gxVNbbV2GawVFGeNYZIuEmPEy1BTfI4DJHGwHdB7fovUxgjnuBYbXk6Da3bcyb8xfVFu s+ScLrkk51RW3YxeRytghCNT41znUoseoKmlJ9l205AKUl/smG2DQ1SW8Cs1nFIv9t2a Y+BF23KP2iRh/TnwX3/752aF4u6Tox7FqJi6FNwlou4lSdbhvfkXyAKNjGtz4eCCm2j7 W/e40KT18vdFhtxnodwWO42ITtIouSuyGTDfCo/qG9cbB74F6GzntQ9D1GgOwpAT4dvQ mV9Q== X-Gm-Message-State: AOAM531un8VH+H006vzpSj1yq37H9X62zSTHegewXw75Itc2S3y7t/vD WYIq6GbsltHysrdFK7DuGRvvkQ== X-Google-Smtp-Source: ABdhPJwvQWZAgbb/Eb7X9BWKVi/U2cWrX6hbe9Fc2xdSblcxGqBDYCbMSiSNX5mQHXRp5rHZVQrc4w== X-Received: by 2002:a37:6711:: with SMTP id b17mr20971175qkc.332.1618326064629; Tue, 13 Apr 2021 08:01:04 -0700 (PDT) Received: from [192.168.1.132] ([177.194.41.149]) by smtp.gmail.com with ESMTPSA id p185sm2250107qke.10.2021.04.13.08.01.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Apr 2021 08:01:04 -0700 (PDT) Subject: Re: [COMMITTED] arm: update libm test ulps To: Szabolcs Nagy , Vineet Gupta Cc: "libc-alpha@sourceware.org" , Carlos O'Donell , Joseph Myers References: <20210408085827.5369-1-szabolcs.nagy@arm.com> <20210413095214.GV23289@arm.com> From: Adhemerval Zanella Message-ID: <6fd7e855-3de3-3044-d56e-14ca1f0cd717@linaro.org> Date: Tue, 13 Apr 2021 12:01:01 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210413095214.GV23289@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 15:01:08 -0000 On 13/04/2021 06:52, Szabolcs Nagy wrote: > The 04/11/2021 18:04, Vineet Gupta wrote: >> On 4/8/21 1:58 AM, Szabolcs Nagy via Libc-alpha wrote: >>> Updated after commits 9acda61d94acc5348c2330f2519a14d1a4a37e73 >>> and 43576de04afc6a0896a3ecc094e1581069a0652a. >> >> Is there a better way for this to be done at the time of original change >> other than running the tests on all affected architectures. arches >> always seem to be chasing these kind of changes ... > > i think there are only small variations between targets for > float and double, so the ulp error limits for those could be > shared (unless a target has its own implementation with > different quality requirement for some reason). > > long double is more target specific. i think the tests could > be organised such that each sysdeps/ieee754/* directory has > its own ulp limits file and the target picks up the right one. > > and libmvec needs target specific ulp limits. > > i don't know how hard it would be to implement this. > The math/libm-test-support.c imposes maximum ulp limits depending of the underling type: 228 if (testing_ibm128) 229 /* The documented accuracy of IBM long double division is 3ulp 230 (see libgcc/config/rs6000/ibm-ldouble-format), so do not 231 require better accuracy for libm functions that are exactly 232 defined for other formats. */ 233 max_valid_error = exact ? 3 : 16; 234 else 235 max_valid_error = exact ? 0 : 9; And if I recall correctly there was a suggestion to consolidate and/or remove the ulps file altogether and use the maximum valid error as the threshold to report regressions. The only drawback I see of moving towards it is each architecture won't see if some change has degraded the function precision. But I tend to agree that using per-architecture ulp files do not add much, since arch maintainer tend todig into the precision issues only when it is higher the the tests threshold.