> I feel like keeping the variable separate from CHPL_TARGET_PLATFORM would
> keep things simpler from a maintenance of Makefiles and env scripts
> perspective. If kept together, most scripts would just need to split it
> apart right away anyways. The instruction set applies more to the compiler
> and would be used in the Makefile.{gnu|intel|...} files rather than
> Makefile.{linux64|darwin|...}.I'm definitely open to that as well. If we did combine them, we could always have a chplenv/proc script that did the teasing apart for us, but if we thought we always wanted to split them (i.e., if there was no benefit to a unified variable), doing so from the start is probably cleaner. >> Instead of (e.g.) core-avx2 I think the modifiers should be something >> like the values accepted in gcc's -mtune options, which name various >> implementations of the architecture (example: linux64-pentium4) rather >> than specific features of the ISA. > > I tend to agree, but GCC doesn't make this easy on us... (even when I > pretend that 4.7 is the new baseline): > > http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc/i386-and-x86_002d64-Options.htm > l#i386-and-x86_002d64-Options > > http://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/i386-and-x86-64-Options.html#i3 > 86-and-x86-64-Options > > It seems like taking the 4.9 cpu-type options and then mapping backwards > onto the older names might be the way to go there. We could fall back to > the next lower ISA if the older compiler doesn't have an exact match for, > say, broadwell as an example. I chose core-avx2 simply by grabbing a name out of Michael's mail. I think it's reasonable (and probably preferable) for Chapel's Makefiles to do something with this value prior to passing it blindly on to gcc, so would agree that taking the high road names suggested by 4.9 and mapping them back to other options for older gcc's seems attractive (even though there's some degree of work for us up-front, and ongoing to an extent, as new ISAs come along). -Brad ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
