From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 1DC95421F0 for ; Tue, 29 Mar 2022 13:14:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 819CA68B2AE; Tue, 29 Mar 2022 16:14:07 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6E9C168A6D2 for ; Tue, 29 Mar 2022 16:14:01 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 22TDE0gt023543-22TDE0gu023543; Tue, 29 Mar 2022 16:14:00 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id B1DE3A143A; Tue, 29 Mar 2022 16:14:00 +0300 (EEST) Date: Tue, 29 Mar 2022 16:13:59 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <20220325185257.513933-4-bavison@riscosopen.org> Message-ID: References: <20220317185819.466470-1-bavison@riscosopen.org> <20220325185257.513933-1-bavison@riscosopen.org> <20220325185257.513933-4-bavison@riscosopen.org> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH 03/10] checkasm: Add idctdsp add/put-pixels-clamped tests X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: Ben Avison Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, 25 Mar 2022, Ben Avison wrote: > Disable ff_add_pixels_clamped_arm, which was found to fail the test. As this > is normally only used for Arms prior to Armv6 (ARM11) it seems quite unlikely > that anyone is still using this, so I haven't put in the effort to debug it. I had a look at this function, and I see that the overflow checks are using tst r6, #0x100 to see whether the addition overflowed (either above or below). However, if block[] was e.g. 0x200, it's possible to overflow without setting this bit at all. If it would be the case that the valid range of block[] values would be e.g. [-255,255], then this kind of overflow checking would work though. (As there exists assembly for armv6, then this function probably hasn't been used much in modern times, so this doesn't say much about what values actually are used here.) Secondly, the clamping seems to be done with movne r6, r5, lsr #24 However that should use asr, not lsr, I think, to get proper clamping in both ends? Thirdly - the added test also occasionally fails for the other existing functions (armv6, neon) and the newly added aarch64 neon version. If you have e.g. src[] = 32767, dst[] = 255, then the widening 8->16 addition will overflow, as there's no operation that both widens and clamps at the same time. I think this is reason to limit the range of src[] at least somewhat in the test, since I don't think the full 16 bit signed range actually is relevant here. // Martin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".