Date: Wed, 05 Apr 2017 07:01:40 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 218387] -march=native or any specific CPU with clang seems to produce a lot of x87 instructions Message-ID: <bug-218387-8-LSvD1rgyc0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-218387-8@https.bugs.freebsd.org/bugzilla/> References: <bug-218387-8@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=3D218387 Dimitry Andric <dim@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|freebsd-bugs@FreeBSD.org |dim@FreeBSD.org --- Comment #4 from Dimitry Andric <dim@FreeBSD.org> --- (In reply to Adam Stylinski from comment #0) > I think this is a bug, but perhaps I just think it is because the behavior > diverges from GCC by quite a bit. >=20 > When you compile an application that does floating point math with clang = in > current right now, specifying -march=3Dnative or -march=3Dsandybridge or = btver2 > or any number of CPUs I tried to target produces predominantly x87 > instructions. Typically GCC and most other compilers I've seen default to > targeting SSE instructions, instead. Do you have any concrete test case? I.e a minimized C or C++ program, with = the complete command line used to compile it, and pointers to the assembly where you think it is invalid? (Note that x87 instructions are still perfectly v= alid on even the newest x86 CPUs.) > If you specify -march=3Dx86-64, you get the results you'd expect > (predominantly SSE2 instructions for floating point). This leads me to > believe this is a bug, for most everything SSE units should be the most > optimal. There are a few parts in the FreeBSD source tree which go out of their way = to avoid SSE, so you might have hit those. Again, without a concrete example = it is not possible to say if there is any problem. (In reply to Adam Stylinski from comment #1) > Ahh, evidently this isn't a new issue. Any value of -march that is later > than nocona results in x87 instructions being emitted all over the binary. >=20 > I'd still consider it a bug, though, as Apple & Linux's clang ports appear > to have correct behavior for these values. I am highly skeptical about that, since there is no special "FreeBSD float" handling in LLVM or Clang. But if you provide a good test case, I can like= ly take it upstream. --=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-218387-8-LSvD1rgyc0>