https://bugzilla.suse.com/show_bug.cgi?id=1212101 https://bugzilla.suse.com/show_bug.cgi?id=1212101#c82 Lee Salzman <lsalzman@mozilla.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lsalzman@mozilla.com Flags| |needinfo?(rguenther@suse.co | |m) --- Comment #82 from Lee Salzman <lsalzman@mozilla.com> --- (In reply to Richard Biener from comment #79)
Btw, the code actually instantiates skvx::Vec<> stuff via
namespace avx {
template <typename T> static void memsetT(T buffer[], T value, int count) {
static constexpr int N = 32 / sizeof(T);
static_assert(N > 0, "T is too big for memsetT");
skvx::Vec<N,T> wideValue(value); while (count >= N) {
wideValue.store(buffer); buffer += N; count -= N; }
while (count --> 0) { *buffer++ = value; } }
inline void memset16(uint16_t buffer[], uint16_t value, int count) { memsetT(buffer, value, count); } ... }
and in SkOpts_avx.cpp:
namespace SkOpts { void Init_avx() { memset16 = avx::memset16; ...
and it expects everything to be fully optimized, eliminating all used template instantiations. But at the time we stream out for LTO that does not have happened.
So I don't see how we can avoid this issue besides inventing some "DWIM" mechanism here.
I would suggest to add -fno-lto to all TUs that are built with extra machine specific flags as workaround.
Richard, would just adding -fno-lto to the flags for the SkOpts_foo.cpp files be sufficient to work around this on your end for GCC builds? I am willing to add this to Firefox's moz.builds to just make this easy. If GCC will let us selectively disable LTO on certain files like that, I am on board. -- You are receiving this mail because: You are the assignee for the bug.