[FFmpeg-devel] [PATCH] bswap: add macros to byteswap constants

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Thu, Apr 29, 2010 at 03:15:59PM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Thu, Apr 29, 2010 at 02:26:50PM +0100, Mans Rullgard wrote:
>> >> The normal byteswap functions might use inline asm which is suboptimal
>> >> with constants (and cannot be used in static initialisers), so special
>> >> macros for constants only is needed.
>> >> 
>> >> We should not rely on the gcc __builtin_constant_p() test since it is
>> >> not always available.
>> >
>> > if its not available then this kind of optimization is not possible
>> 
>> I intended these to be used where the value is a constant expression,
>> e.g. bswap(0x1234).  This would be useful for building constant tables
>> that depend on the byte order.
>> 
>> > adding even more complexity, ifdefery, and burden to support partial
>> > optimizations in extreemly primitive compilers is imho not a good idea.
>> 
>> Not all non-gcc compilers are extremely primitive.  In fact, many of
>> them are far superior.
>
> they can optimize constant asm() away at compiletime ?

Not that I know of, but there are other ways of being superior, such
as generating faster code.

>> > If one wants optimized
>> > code a compiler with the (optimization relevant) feature set of gcc is
>> > imho the minimum requirement.
>> > thats besides that this patch is just a brick of a huge wall that would
>> > be needed for this hack, you would need to duplicate every use of le/be
>> > code as well. The bitstream readers is just the next step, and then all
>> > uses of the bitstream code would have to be reviewed if the values are
>> > compiletime constant or not. Thats huge amounts of work for a primitive
>> > compiler. id much rather completely drop support for such compilers
>> 
>> You (deliberately?) misunderstood the purpose of this patch.
>
> i didnt reject this patch, thats just a rejection of me maintaining
> any hacks to support "constant" optimizations in compilers that dont
> support an equivalent of __builtin_constant_p and neither can handle
> const/pure attributes with asm

I have no plans to add any such hacks at the moment, so you don't need
to worry.  Right now I was only thinking of constant initialisers.

-- 
M?ns Rullg?rd
mans at mansr.com