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 BDB60138989 for ; Sat, 2 May 2015 11:37:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BEFD4E0872; Sat, 2 May 2015 11:37:25 +0000 (UTC) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 748AFE07E8 for ; Sat, 2 May 2015 11:37:24 +0000 (UTC) Received: by wizk4 with SMTP id k4so75746158wiz.1 for ; Sat, 02 May 2015 04:37:23 -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=9DSQRVFtl6dkOuHJJHmlvfRthjDk0FDSgvRMT8WTshA=; b=WzHIkp1TcOmCt2aOPkLZIZTcxAztSx3S7B9GwX/dZYuf8mii+EdxiA9UJP0+0ydifz 2gEYDabfFrWe4hyZGAQHfco1Jd/AsF3ALVTp2v/3oeo1B5TNF3xLJsb7PL53AdIiTqwu MYchlOdaXvS0E1AZHi43bEQMrZS1YoKsebwEr1oOu+4K1Kp3cnfPQt1+KKnLNezCEZLQ O/QZ/heotyl7ojHjRztXTcKUeNRaGYB+/73OBAIlauO6Fy9qF8ETs6ZUYKXID5uFt6j5 r7VBgncVOaFma1++o5PoFFdJBPZkWyYvIp8uRiEnHlGDiGAiXvNypRe4b/tObRWjrB9q Z8dw== X-Received: by 10.195.17.232 with SMTP id gh8mr25063322wjd.145.1430566643238; Sat, 02 May 2015 04:37:23 -0700 (PDT) Received: from [192.168.178.21] (p4FC11A75.dip0.t-ipconnect.de. [79.193.26.117]) by mx.google.com with ESMTPSA id ex2sm11433928wjd.28.2015.05.02.04.37.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 04:37:22 -0700 (PDT) Message-ID: <5544B6F2.8040508@googlemail.com> Date: Sat, 02 May 2015 13:37:22 +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> <5544B2AB.1010700@googlemail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: e17ae1fb-904a-4717-a5f0-5046047281bb X-Archives-Hash: 4ecb3bdb59c4343b30a9abafad3ab0ce Am 02.05.2015 um 13:25 schrieb Nikos Chantziaras: > On 02/05/15 14:19, Volker Armin Hemmann wrote: >> 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 > > Not sure what you're trying to say. > > > that simd is not save in kernel if not carefully guarded. Really people, just don't fuck around with the cflags.