[FFmpeg-devel] [PATCH] avcodec/x86/mathops: use constrained immediate operands
James Almer
jamrial at gmail.com
Sun Jul 16 14:55:43 EEST 2023
On 7/16/2023 6:23 AM, Rémi Denis-Courmont wrote:
> Le sunnuntaina 16. heinäkuuta 2023, 2.58.32 EEST James Almer a écrit :
>> Should fix assembling with binutil as >= 2.41
>>
>> Signed-off-by: James Almer <jamrial at gmail.com>
>> ---
>> This is IMO a big breakage. binutil's as has until now clipped these values
>> on its own, and never required the compiler to do it.
>
> TBH, silently clipping immediate constants sounds like a nasty bug that could
> cause really nasty suprises if somebody every passes an out-of-range constant.
We're passing it out or range constants alright. I tried adding an
av_assert0((uint8_t)(-s) <= 31) and most fate tests started failing.
> This has happened to me many times, typically with incidentally out-of-range
> immediate offsets in loads/stores.
>
> (...)
>
>> __asm__ ("shrl %1, %0\n\t"
>> : "+r" (a)
>> - : "ic" ((uint8_t)(-s))
>> + : "Ic" ((uint8_t)(-s))
>
> Note that this is not equivalent. Now, if `s` is constant but out of range,
> the compiler will be required to fit it. And it does that by moving it into
> ECX. This is probably not what you want.
>
> AFAICT, you should keep the constraint as it is, and fix the operand value
> instead by masking it, e.g.:
>
> if (__builtin_constant_p(s))
> __asm__ ("shrl %1, %0\n\t"
> : "+r" (a)
> : "i" ((-s) & 0x1f)
> );
> else
> __asm__ ("shrl %1, %0\n\t"
> : "+r" (a)
> : "c" (-s)
> );
>
> (Not sure if the the 0x1f mask is correct, but you get the idea.)
It is, just tested.
More information about the ffmpeg-devel
mailing list