On 01/08/16 09:09, Martin Storsjö wrote:
> AV_WN64 is meant for unaligned data, but the existing av_alias* unions
> (without a definition for the av_alias attribute - we don't have one
> for MSVC) indicate to the compiler that they would have sufficient
> alignment for normal access, i.e. the compiler is free to assume
> 8 byte alignment.
>
> On ARM, this makes sure that AV_WN64 (or two consecutive AV_WN32) is
> done with two str instructions instead of one strd.
> ---
> Or should we define av_alias to __unaligned in attributes.h instead?
> ---
> libavutil/intreadwrite.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavutil/intreadwrite.h b/libavutil/intreadwrite.h
> index f77fd60..0ba9254 100644
> --- a/libavutil/intreadwrite.h
> +++ b/libavutil/intreadwrite.h
> @@ -197,6 +197,11 @@ union unaligned_16 { uint16_t l; }
> __attribute__((packed)) av_alias;
> # define AV_RN(s, p) (*((const __unaligned uint##s##_t*)(p)))
> # define AV_WN(s, p, v) (*((__unaligned uint##s##_t*)(p)) = (v))
>
> +#elif defined(_MSC_VER) && (defined(_M_ARM) || defined(_M_X64))
> +
> +# define AV_RN(s, p) (*((const __unaligned uint##s##_t*)(p)))
> +# define AV_WN(s, p, v) (*((__unaligned uint##s##_t*)(p)) = (v))
> +
> #elif AV_HAVE_FAST_UNALIGNED
>
> # define AV_RN(s, p) (((const av_alias##s*)(p))->u##s)
>
Maybe add the additional conditions to the __DECC block?
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
