[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Disappeared flag: -maes on -march=ivybridge, present in -march=native
From:       Thiago Macieira <thiago.macieira () intel ! com>
Date:       2019-07-29 5:47:37
Message-ID: 23706441.rAQY1eQIVV () tjmaciei-mobl1
[Download RAW message or body]

On Sunday, 28 July 2019 16:16:21 PDT Kevin Weidemann wrote:
> Hello everyone,
> 
> I have recently randomly discovered the fact, that building with
> `-march=ivybridge` does not necessarily produce the same output as
> `-march=native` on an Intel Core i7 3770K (Ivy Bridge).
> 
> In particular, `-march=native` sets `-maes` whilst `-march=ivybridge`
> does not.

That is the expected behaviour today. -march=native gives you what your CPU 
has, even if it's different from what a baseline CPU architecture would 
provide. As an example, if you ran GCC inside a virtual machine that somehow 
turned some CPU features off, you'd get a fully working build for your CPU 
using all CPU features you can use.

That's different from LLVM, which attempts to find which CPU most closely 
matches yours. In that VM scenario, it would either disable some features you 
could use or enable ones you can't.

> After carefully considering the option that I'm in fact turning crazy
> (e.g. I triple-checked that `-march=native` really does set
> `-march=ivybridge` and `-mtune=ivybridge`), it seems like while this is
> the case on the GCC version that I'm actively using (9.1.0), it is not
> on a different machine (6.3.0 20170516 (Debian 6.3.0-18+deb9u1)).

True. Older versions of GCC turned AES on for -march=westmere and up, but not 
anymore. The commit you found changed that.

> Is this an oversight or mistake?

Neither, it's intentional.

Not all Westmere, Sandybridge, Ivybridge, Haswell or Broadwell machines have 
AES.[*] Therefore, if you want to target *all* Ivybridges, you should not be 
getting AES turned on by default. You should be doing runtime checking.

This specifically affected us in the Clear Linux distribution, since we build 
the entire distro with -march=westmere as a baseline. Up until earlier this 
year, with the GCC 9 upgrade, we were turning users away who had machines 
without AES, since our installer complained (still does, I think) because GCC 
had set the __AES__ macro, even though I found absolutely no software in the 
distro using AES without CPUID checks.

[*] I have yet to see a Skylake or up SKU listed in https://ark.intel.com 
without AES, but it's possible one will show up in the future.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



[prev in list] [next in list] [prev in thread] [next in thread]