[FFmpeg-devel] fate : clang x86

[Michael Niedermayer]

On Tue, Aug 24, 2010 at 11:48:45AM -0400, Jason Garrett-Glaser wrote:
> On Tue, Aug 24, 2010 at 11:19 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Mon, Aug 23, 2010 at 06:57:20PM -0700, Eli Friedman wrote:
> >> 2010/8/23 M?ns Rullg?rd <mans at mansr.com>:
> >> > Eli Friedman <eli.friedman at gmail.com> writes:
> >> >
> >> >> 2010/8/21 M?ns Rullg?rd <mans at mansr.com>:
> >> >>> Eli Friedman <eli.friedman at gmail.com> writes:
> >> >>>
> >> >>>> 2010/8/21 M?ns Rullg?rd <mans at mansr.com>:
> >> >>>>> castet.matthieu at free.fr writes:
> >> >>>>>
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>> on freebsd "-mllvm -regalloc=fast" cflags are used to make clang/llvm accept
> >> >>>>>> some inline asm.
> >> >>>>>>
> >> >>>>>> May be we should do the same on linux ?
> >> >>>>>
> >> >>>>> I tried and failed to figure out what that flag does. ?I assume it
> >> >>>>> does something with the register allocator, but I'd like to know what.
> >> >>>>
> >> >>>> It's a workaround of sorts for
> >> >>>> http://llvm.org/bugs/show_bug.cgi?id=4668 . ?LLVM essentially has two
> >> >>>> register allocator implementations: one is the "fast" allocator, which
> >> >>>> is a local register allocator used for -O0, and the other is the
> >> >>>> "linear scan" allocator, which is the slower global register allocator
> >> >>>> used for -O1+. ?"-mllvm -regalloc=fast" forces the use of the "fast"
> >> >>>> allocator, which leads to slower generated code, but isn't affected by
> >> >>>> the bug in question.
> >> >>>
> >> >>> Sounds like it's not suitable for production use. ?Any chance they'll
> >> >>> fix the bug?
> >> >>
> >> >> In the near future? ?Not very likely... from what I understand, it's a
> >> >> relatively difficult issue to solve, and bugs rejecting valid inline
> >> >> asm are generally considered low priority for the people who know the
> >> >> register allocator well enough to fix this.
> >> >
> >> > That leaves two options:
> >> >
> >
> >> > 1. Declare clang officially unsupported for x86_32.
> >
> > ok with me
> >
> >
> >> > 2. Fix our code.
> >>
> >> Attached attempts option 2. ?It's essentially a straight port of the
> >> inline asm to yasm, with a couple minor changes to reduce the number
> >> of arguments. ?This removes all the inline asm blocks from
> >> mpegvideo_mmx_template.c, which allows clang to successfully build
> >> ffmpeg. ?Passes regression tests.
> >
> > and is slower due to additional call overhead
> 
> Why would it have additional overhead?  Both are called by the same
> function pointer.

-            : "+a" (last_non_zero_p1)
-            : "r" (block+64), "r" (qmat), "r" (bias),
-              "r" (inv_zigzag_direct16+64), "r" (temp_block+64)
-        );
+        last_non_zero_p1 =
+            RENAMEcore(ff_dct_quantize_core_h263)(block+64, qmat, bias,
+                                                 inv_zigzag_direct16+64,
+                                                 temp_block+64, overflow);
     }else{ // FMT_H263


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100824/a7d3d828/attachment.pgp>