[FFmpeg-devel] fate : clang x86

[Måns Rullgård]

Alex Converse <alex.converse 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?
>>
>
> While "asm()" itself is standard GCC constraints are not. LLVM is free
> to do whatever it likes in regard to ASM constraints. (Now clang has a
> goal to be as GCC compatible as possible, so it still is an issue but)
> I wouldn't say this bug makes clang not suitable for production use.

I meant that -regalloc=fast is not suitable for production.  Hence my
question regarding the chances of getting the good allocator working
for this code.  If that is not going to happen, and I somehow doubt it
will, we need to change our code.

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