Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jul 2021 16:53:43 +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-snhD2M2IlR@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 #9 from Ed Maste <emaste@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?

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 optimizatio=
n...
> 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 i=
s a
> compiler (and/or linker) bug, is not it? Would it make sense to bring thi=
s 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 faste=
st
> 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 ha=
ve
strong feelings on which it is.

--=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-snhD2M2IlR>