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

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 12 Jul 2021 16:53:43 +0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257124

--- Comment #9 from Ed Maste <emaste_at_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?

amd64 has r8 through r15 in addition to the 64-bit versions of the common
registers (rax, rbx etc.)

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

Perhaps a non-functional optimization, but indeed it doesn't really matter.

> 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?

Perhaps, although I suspect there will not be a lot of interest in
investigating i386-specific optimization issues.

> 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.

Indeed, no disagreement that optimization is desirable on multimedia ports. My
point is just that there is likely to be little developer effort available
(upstream or in FreeBSD) to work on these issues on i386.

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

I believe it is disabled by default on all archs right now?

The option should be a warning, error, or not available on i386; I don't have
strong feelings on which it is.

-- 
You are receiving this mail because:
You are the assignee for the bug.
Received on Mon Jul 12 2021 - 16:53:43 UTC

Original text of this message