shithub: openh264

Info  •  Files  •  Log  •  Branches

Add attributes incidating intentional data type aliasing

Interpreting data of one type via a pointer of a different type is an
aliasing violating. This means that a compiler optimizer's analyzer
can assume that data loaded into an array as uint32_t isn't related
to data read out from the same array as uint64_t, and e.g. reorder
loads/stores.

Since these structs are intentionally used to load data via pointers
of a wrong size, tell the compiler that these accesses may alias
other reads.

This fixes the GetIntraPredictorTest tests of WelsI4x4LumaPredV_c
and WelsI4x4LumaPredH_c. (The compiler optimizer did the wrong thing
as long as WelsFillingPred8to16_c or WelsFillingPred8x2to16_c were
inlined into the calling function.)

--- a/codec/common/inc/ls_defines.h

+++ b/codec/common/inc/ls_defines.h

@@ -40,13 +40,13 @@

 struct tagUnaligned_64 {

   uint64_t l;

-} __attribute__ ((packed));

+} __attribute__ ((packed)) __attribute__ ((may_alias));

 struct tagUnaligned_32 {

   uint32_t l;

-} __attribute__ ((packed));

+} __attribute__ ((packed)) __attribute__ ((may_alias));

 struct tagUnaligned_16 {

   uint16_t l;

-} __attribute__ ((packed));

+} __attribute__ ((packed)) __attribute__ ((may_alias));

 #define LD16(a) (((struct tagUnaligned_16 *) (a))->l)

 #define LD32(a) (((struct tagUnaligned_32 *) (a))->l)

@@ -54,7 +54,7 @@

 #define STRUCTA(size, align) struct tagUnaligned_##size##_##align {\

     uint##size##_t l; \

-} __attribute__ ((aligned(align)))

+} __attribute__ ((aligned(align))) __attribute__ ((may_alias))

 STRUCTA (16, 2);

 STRUCTA (32, 2);

 STRUCTA (32, 4);