Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 05 Jan 2011 08:50:40 -0600
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Gleb Kurtsou <gleb.kurtsou@gmail.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, Dimitry Andric <dim@freebsd.org>, svn-src-head@freebsd.org, Alexander Best <arundel@freebsd.org>
Subject:   Re: svn commit: r216977 - in head/libexec/rtld-elf: amd64 i386
Message-ID:  <4D248540.3030602@freebsd.org>
In-Reply-To: <201101050928.30748.jhb@freebsd.org>
References:  <201101042051.p04KpSGk054564@svn.freebsd.org> <201101050759.50877.jhb@freebsd.org> <4D2473C6.40102@FreeBSD.org> <201101050928.30748.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 01/05/11 08:28, John Baldwin wrote:
> On Wednesday, January 05, 2011 8:36:06 am Dimitry Andric wrote:
>> On 2011-01-05 13:59, John Baldwin wrote:
>>>> Why not to add NO_HWFLOAT knob (or similar) into makefile
>>>> infrastructure. And set CFLAGS accordingly, depending on CC, arch, etc.
>>>> These flags are getting rather common in tree.
>>> It strikes me that we really want clang/gcc to have some sort of
>>> '-mno-hwfloat' so we don't keep having to add new flags in the future.
>> This is not just about floats, clang can also use SSE/AVX instructions
>> for e.g.  memset(), memcpy() and the like, or even for structure
>> assignments.
> Yes, but the thing that all these extensions have in common is that they use
> FPU state (i.e. subject to DNA traps, managed via *SAVE and *RSTOR, etc.)
> and that is the problem with using them in boot code or rtld.  What I would
> want a -mno-hwfloat flag to do is to disable use of anything that would
> require working FPU state handling.

You would also want this to be cross-platform, in which case it's more 
than floating point. E.g. on powerpc, you also want to disable both FP 
and vector extensions, which use separate sets of instructions and 
registers. I guess overriding CPU type to be something very old (386?) 
potentially deoptimizes the code?
-Nathan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D248540.3030602>