[Bug 257124] multimedia/ffmpeg: Fails to link: ld: error: inline assembly requires more registers than available at line [on i386 with LTO option]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257124

--- Comment #8 from Dimitry Andric <dim@FreeBSD.org> ---
(In reply to Mikhail Teterin from comment #7)
> I'm confused... Is not the number of registers the same on the same processor -- whether it is running in 32- or 64-bit mode? Even if they are named/accessed differently?

No. The i386 architecture has 8 general purpose registers (32 bit only), of
which only 6 are freely usable (as %esp and %ebp are used for the stack). The
amd64 architecture has 16 general purpose registers (64 bit), of which 14 are
freely usable.

Certain inline assembly constructs are parameterized such that the compiler
can't satisfy the number of free registers asked, and then you get this error.
If such assembly is critical, it is better to write the whole routines in .S
files instead of attempting to do it inline in C or C++.


> Frankly, if optimization results in errors, then it is not an optimization... I don't blame anyone here for the failure, just debating terminology :-)

The problem is that once you start inlining, assumptions on how many registers
are available might become invalid, as many more variables that were first on
some stack frame are now put in registers.


> If the otherwise valid code cannot be compiled (and/or linked), than it is a compiler (and/or linker) bug, is not it? Would it make sense to bring this up with LLVM-project directly?

You could try, but I think they'll say that your inline assembly is bad (even
if you could point to the particular piece of inline assembly, which we can't,
unfortunately). There is never a guarantee that a compiler can instantiate any
inline assembly, it is really a best effort. Again, if you need full control at
that level, you should write your assembly code in assembly sources. FFmpeg
does this for a lot of things using nasm or yasm, but for some reason (probably
historical?) they still put a whole bunch of inline assembly in C files.


>I would've thought, with multimedia every CPU-instruction counts... Even if the hardware is fast enough for regular realtime playback, when performing format-conversions, CPU is almost always the bottleneck even on the fastest computers.

I'm sure nobody will use an ancient i386 only machine as an FFmpeg conversion
box. :)


> Perhaps, the option should carry a warning -- and be disabled by default on i386 -- but disabling it altogether seems too drastic.

I'm fine with that, but people will likely encounter the errors mentioned in
the beginning, and submit more bugs. You could maybe use a BROKEN= syntax in
the Makefile? I'm not entirely sure how that works though.

-- 
You are receiving this mail because:
You are the assignee for the bug.