From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D6EC7138989 for ; Sat, 2 May 2015 11:19:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4BE5FE0872; Sat, 2 May 2015 11:19:11 +0000 (UTC) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 11A02E0866 for ; Sat, 2 May 2015 11:19:09 +0000 (UTC) Received: by wgyo15 with SMTP id o15so110479298wgy.2 for ; Sat, 02 May 2015 04:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/SgO1SffZDI/LOIrIH8su3gJQe2MoTVXXsbSkC27PL4=; b=bZbfHGjynr2NsDY0IupZ0IyABqTtHM8+44rbn3TpyvGaWXs6TIbuWPp7JU7L6Z3uco AVJCKvZvdMzO23n2NTUIFJnwS/mPlMEGouQOD07GbUoIARqEKUNKbmwEfzNx3ziZl/Nl yPXkiTOCTixWEzqgF2k49mif9ZwYA9hJf9IrWH1QBD6gOyZP9jDnbvvV+bp+lpcX0H1K aPdHhN7JEJFtIRYRi2LFqfGeeBivONdjcURKDrMrJaRNDkrvdF5dVipQTbkxQeyWCGDJ 0eMvFj0k13FQ8RGNS9jjF2ZFm9ctNIYToDPaI7hJu8VJI0PcNIuvtn5UC2gHCDh/WzGG svKg== X-Received: by 10.194.60.43 with SMTP id e11mr26294863wjr.36.1430565548816; Sat, 02 May 2015 04:19:08 -0700 (PDT) Received: from [192.168.178.21] (p4FC11A75.dip0.t-ipconnect.de. [79.193.26.117]) by mx.google.com with ESMTPSA id js3sm11400839wjc.5.2015.05.02.04.19.07 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 04:19:07 -0700 (PDT) Message-ID: <5544B2AB.1010700@googlemail.com> Date: Sat, 02 May 2015 13:19:07 +0200 From: Volker Armin Hemmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: CFLAGs for kernel compilation References: <5540C101.70906@ramses-pyramidenbau.de> <20150430123819.b72d8b39bd60a912b7c7fde5@gentoo.org> <20150501104402.27d943c901f638942262d3d1@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 25905f89-e9e4-4268-89b6-e60e1480a69f X-Archives-Hash: e8e345b787eae07c266f3ca14db8e7ce Am 02.05.2015 um 07:04 schrieb Nikos Chantziaras: > On 01/05/15 10:44, Andrew Savchenko wrote: >> On Fri, 1 May 2015 05:09:51 +0000 (UTC) Martin Vaeth wrote: >>> Andrew Savchenko wrote: >>>> >>>> That's why kernel makes sure that no floating point instructions >>>> sneaks in using CFLAGS, you may see a lot of -mno-${intrucion_set} >>>> flags when running make -V. >>> >>> So it should be sufficient that the kernel does not use "float" >>> or "double", shouldn't it? >> >> No. Optimizer paths may be very unobvious, i.e. I'll not be >> surprised if under some conditions vectorizer may use float >> instructions for int code. > > The kernel uses -O2 and several -march variants (e.g. -march=core2). > Several other options are used to prevent GCC from generating > unsuitable code. > > Specifying another -march variant does not affect the optimizer > though. It only affects the code generator. If you don't modify the > other CFLAGS and only change -march, you will not get FP instructions > unless you use FP in the code. > > Also, I'd be very interested to see *any* optimization that would > somehow transform integer code to FP code (note that SIMD is not FP > and is perfectly fine in the kernel.) In fact, optimizers tend to > transform FP into SIMD, at least on x86 (and other architectures that > have fast SIMD instructions.) If I inspect the generated assembly from > GCC or Clang, I cannot find FP anywhere, even for code using "float" > and "double" operations. They get converted to SIMD on modern CPUs > (unless you specify a compiler flag that tells it to use the FPU, for > example if you need 80-bit extended precision, which is supported by > the x86 FPU.) > > > http://www.agner.org/optimize/calling_conventions.pdf Device drivers under Linux Linux systems use lazy saving of floating point registers and vector registers. This means that these registers are not saved and restored on every task switch. Instead they are saved/restored on the first access after a task switch. This method saves time in case no more than one thread uses these registers. The lazy saving scheme is not supported in kernel mode. Any device driver that attempts to use these registers improperly will cause an exception that will probably make the system crash. A device driver that needs to use vector registers must first save these registers by calling the function kernel_fpu_begin() and restore the registers by calling kernel_fpu_end() before returning or sleeping. These functions also prevent pre-emptive interruption of the device driver which could otherwise mess up the registers. kernel_fpu_begin() saves all floating point registers and vector registers if available. There is no red zone in 64-bit Linux kernel mode. The programmer should be aware of these restrictions if calling any other library than the system kernel libraries from a device driver.