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" <vapier@xxxxxxxxxx> 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
