From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B60731396D0 for ; Wed, 6 Sep 2017 04:32:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F15FB1FC0A0; Wed, 6 Sep 2017 04:32:29 +0000 (UTC) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 A34C41FC093 for ; Wed, 6 Sep 2017 04:32:29 +0000 (UTC) Received: by mail-yw0-x22a.google.com with SMTP id s62so3224746ywg.0 for ; Tue, 05 Sep 2017 21:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3jyB3D3y7qkZgGnln4Zpk1J0f7Mn/2zuOiccf7MOyRA=; b=IDOEXKhRkuv5ZxL7Q6XbRN3RrctEzbOnMZ96MKZZXOMSQIrVsbB5TtauXRe9zdrVQs POmUU+UnTIhUtGa3hUJznJY8Cu/zrYHKtF1VbjRq3vFl6coAWYfcV+QSvnlRoFB42zpS IxpdI09uXDG5gwjrW+PRAI7UeVDiQzW3YwWN6R9K3Hqb6QhKrBZQR4bEGXMmnrXEHIar qYTfbf13VcFAtqjP8noU9hoBHgsVE/46ZyzX+m7b65CUH0x3PWAmDe5hKGqAlukK9Jpw 1TOh7VcGvGekIoWISewkYZHdGCEj9a1uZbZVua68wNooGGohkzd8TxToXxIqceZpPKbk ZZFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3jyB3D3y7qkZgGnln4Zpk1J0f7Mn/2zuOiccf7MOyRA=; b=tUfLozE7ni7WetGx23I3WYIrUFLtyOiEbkLxlMOAqKQHhCYPxRN4X2pzoptpXbgZyf i0/RiCdx7XW9GQtC2a/fO69+CDyxdYz46NwBn8Z8aTbFN9Ks8deZhqlo0rY6KER5CeJi 3ksln1LFmH+5qmSN70tilmVtpvALWUKBjlv9d5ODpepXbWzg8j/EkjXVsxRUPn2q19xv XlCpnSlnXa+ZQZF2E2ZYNh1Jk2nC+kQhY2SxIPSEap5DAb8o9QF9zxrgiGoOhE+z+kkq 4UHFvEOnYYFFFeSHv13is4e35OpV+fyKkeKqasgTU4xGq4Zl88kYbizhBnIhTFnRFfyL 8/Iw== X-Gm-Message-State: AHPjjUiqi9esMhv4WXoqhkh2ZdEblWyifvSgNlsOnNkG9/LL37ge4jWJ 9ofJZHXh61LAf0Iih16G2MSwWzMuDg== X-Google-Smtp-Source: ADKCNb4JJjiDI/N6kkSvgungMV1S3+ZrWcOC0ayz1uvHI2/6m9UpnMAmtex29eHNXFXUwJNt2RLvQUsn1h/DMCslHrU= X-Received: by 10.129.112.134 with SMTP id l128mr1016818ywc.220.1504672348219; Tue, 05 Sep 2017 21:32:28 -0700 (PDT) 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 Received: by 10.129.211.10 with HTTP; Tue, 5 Sep 2017 21:32:27 -0700 (PDT) In-Reply-To: References: <20170905083727.GA23751@waltdnes.org> From: R0b0t1 Date: Tue, 5 Sep 2017 23:32:27 -0500 Message-ID: Subject: Re: [gentoo-user] Lowest common denominator compile To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 073aafb4-7a47-4eb3-9ce8-bb3a71f8416e X-Archives-Hash: a6b4d6d888555ab5be6db9dd0461e6d1 On Tue, Sep 5, 2017 at 10:43 PM, Grant wrote: >>>>>> Now I'm running into "trap invalid opcode" errors on the older >>>>>> systems. Can I disable some of the newer CPU instruction sets on the >>>>>> master laptop when compiling to hopefully generate binaries that will >>>>>> work on the older systems? >>>>> >>>>> Yes. You need to find out CPU_FLAGS_X86 and "-march=" values the >>>>> machines have, and use that in make.conf. Run the commands... >>>>> >>>>> cpuinfo2cpuflags-x86 >>>>> gcc -c -Q -march=native --help=target | grep march= >>>>> >>>>> ...on the target machines. This will tell you what "native" is and >>>>> what CPU_FLAGS_X86 values to use. >>>>> >>>>> https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options >>>>> lists available "march=" options, and what instruction sets they support. >>>>> E.g. my old core2 desktop shows... >>>>> >>>>> [d531][waltdnes][~] cpuinfo2cpuflags-x86 >>>>> CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3" >>>>> >>>>> [d531][waltdnes][~] gcc -c -Q -march=native --help=target | grep march= >>>>> -march= core2 >>>>> >>>>> >>>>> Unless the laptops are really old, you can probably get away with... >>>>> CFLAGS="-O2 march=core2 -mfpmath=sse -fopenmp -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables" >>>>> >>>>> booby trap 1) Unless all machines are Intel "Atom" family, do *NOT* use >>>>> a "march=" that implements the "movbe" instruction. >>>>> >>>>> booby trap 2) If you throw in any AMD-based machines proceed with care. >>>>> >>>>> Can you post the output of... >>>>> gcc -c -Q -march=native --help=target | grep march= >>>>> ...for all the target machines? >>>> >>>> >>>> Let's see how -mtune=native goes and resort to the above if necessary. >>>> It doesn't look too bad though. >>> >>> >>> emerge -e world has finished and pushed and -mtune=native seems to >>> have solved the issue for now. >>> >> >> You might be interested in "-march=x86-64 -mtune=generic" though this >> will mean you might miss out on some optimizations. > > > If I could miss out on optimizations, what is the advantage compared > to -mtune=native? Better compatibility across CPUs? > Well, having looked it up (again), -march will break backwards compatibility while -mtune=native will not if you stay within a family of processors. So, yes. One of the finer points of -mtune is that is specifies processor cache sizes. If this is set to an incorrect value you could get very poor performance relative to leaving it unset (with -mtune=generic). For the exact differences, try: gcc -march=native -mtune=native -E -v - &1 | grep cc1 echo | gcc -dM -E - -march=native Which will show you the expanded compilation flags and macro definitions, respectively.