Re: Compiling for newer Intel CPUs with an older Intel build system?

[Sean Byland]

Thanks. Targeting the least common denominator ISA to get portable code
works well for many things but in this case I’m curious about getting
better performance than portability.

Sean

On 3/4/16, 12:41 PM, "Mike Frysinger" <address@hidden> wrote:

>On 04 Mar 2016 16:11, Sean Byland wrote:
>> I’m trying to help users get autotools-based projects to compile in our
>>somewhat unique environment. It’s fairly common for users to want to
>>compile on a Intel ivybridge system (node) with Intel broadwell-specific
>>(a superset of CPU instructions) performance optimization to run
>>elsewhere (a compute node). With default options configure won’t handle
>>this scenario because the build system can’t execute the
>>Broadwell-specific x86 instructions. In varying degrees of success
>>configure will work by:
>> 
>>   1.  Setting --build to a slightly different canonical name to the
>>--build name,  indicating to configure that it should do a cross-compile
>> 
>>   2.  Generating a config.cache on the Ivybridge compute node, which
>>shares the majority of the file system with the Sandybridge system and
>>can successfully execute everything. Then point configure on the
>>sandybridge system at the cache generated while using the Ivybridge CPU.
>> 
>>   3.  Setup configure to use a test “launcher,” so configure tests will
>>be launched on the Ivybridge system.
>> 
>> 
>> I like option one because it seems to follow a use-case that the
>>autotools were designed for but I seem to get regular failures because
>>(for example) the packager will use AC_TRY_RUN without defining a
>>sensible “[action-if-cross-compiling]”. I like that option three allows
>>configure’s main code path to function as intended but strongly dislike
>>that it requires use of an Broadwell CPU that won’t always be available
>>for every build and would probably require hacking and/or a configure
>>user to perform packager actions. Option two get’s test results from the
>>desired execution environment, allows configure to run really fast, and
>>only requires minimal use of the Ivybridge system. Is using the cache in
>>this manner generally a bad idea?
>> 
>> 
>> I’d also appreciate any general feedback, in the past my lack of
>>autotools knowledge has led me to “fight” things and so I’d like to
>>avoid deviating too far from what these tools were designed for.
>
>seems like the only thing you need to do is properly set CFLAGS/CXXFLAGS.
>if you want a build that'll work on all x86 systems, then use something
>like:
>       ./configure CFLAGS='-O2 -march=x86-64 ...' CXXFLAGS='-O2 -march=x86-64
>...'
>
>no need to mess with --build or --host, or config.cache.  i'm assuming
>the configure script doesn't attempt to detect CPU extensions via some
>RUN tests ... if it does, then the script should be fixed to do define
>probing and/or add a configure flag to control them (like --disable-mmx).
>-mike