[Bug 218387] -march=native or any specific CPU with clang seems to produce a lot of x87 instructions

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218387

Dimitry Andric <dim at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |In Progress
           Assignee|freebsd-bugs at FreeBSD.org    |dim at FreeBSD.org

--- Comment #4 from Dimitry Andric <dim at 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.
> 
> When you compile an application that does floating point math with clang in
> current right now, specifying -march=native or -march=sandybridge 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 valid
on even the newest x86 CPUs.)


> If you specify -march=x86-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.
> 
> 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 likely
take it upstream.

-- 
You are receiving this mail because:
You are the assignee for the bug.