Date: Mon, 12 Jul 2021 16:37:55 +0000 From: bugzilla-noreply@freebsd.org To: multimedia@FreeBSD.org Subject: [Bug 257124] multimedia/ffmpeg: Fails to link: ld: error: inline assembly requires more registers than available at line [on i386 with LTO option] Message-ID: <bug-257124-12827-gTAQgl91P9@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-257124-12827@https.bugs.freebsd.org/bugzilla/> References: <bug-257124-12827@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257124 --- 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 proce= ssor -- 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). T= he amd64 architecture has 16 general purpose registers (64 bit), of which 14 a= re 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 err= or. 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 optimizatio= n... I don't blame anyone here for the failure, just debating terminology := -) The problem is that once you start inlining, assumptions on how many regist= ers 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 i= s a compiler (and/or linker) bug, is not it? Would it make sense to bring t= his up with LLVM-project directly? You could try, but I think they'll say that your inline assembly is bad (ev= en 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 contro= l 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 (prob= ably historical?) they still put a whole bunch of inline assembly in C files. >I would've thought, with multimedia every CPU-instruction counts... Even i= f the hardware is fast enough for regular realtime playback, when performin= g format-conversions, CPU is almost always the bottleneck even on the faste= st computers. I'm sure nobody will use an ancient i386 only machine as an FFmpeg conversi= on 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=3D syntax= in the Makefile? I'm not entirely sure how that works though. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257124-12827-gTAQgl91P9>