Yes, if we (Chapel) take on the job of defining and maintaining a set of
targeting option (whether in env vars or some other way) and translating
those into target compiler options or whatever, it could end up being
significant work. What if we make the user do that if they need it?
Say, let them set a CHPL_TARGET_COMPILER_OPTIONS environment variable,
which is allowed to contain options we'll give to the target compiler?
greg
On Mon, 5 May 2014, Kyle Brady wrote:
> 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|...}.
>
>> 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.
>
> -Kyle
>
> On 5/5/14, 11:18 AM, "Greg Titus" <[email protected]> wrote:
>
>> Making CHPL_TARGET_PLATFORM more specific sounds fine, but ...
>> - Personally I'd much prefer its values be of the form linux64-<HW>
>> rather than <HW>-linux64, because I'd like the modifiers that create
>> greater specificity to occur after the general concept they modify
>> rather than before it.
>> - 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. The reason is that if you allow
>> people to list individual ISA variants they can create combinations
>> that in fact never existed, plus it might be hard to pick the matching
>> target C compiler option for a given Chapel target arch variant. If
>> you limit them to the specific implementation names at least you know
>> that what they name is a real thing and mapping that to an appropriate
>> target compiler option should be easier.
>>
>> greg
>>
>>
>> On Mon, 5 May 2014, Brad Chamberlain wrote:
>>
>>>
>>>>> So one could consider CHPL_TARGET_PLATFORM something like a noun and
>>>>> CHPL_RT_ARCH something like an adjective?
>>>>
>>>> They are actually a bit more orthogonal than that.
>>>> CHPL_TARGET_PLATFORM is
>>>> more along the lines of what operating system you are using, while
>>>> CHPL_RT_ARCH would be what processor you have in that machine.
>>>
>>> I find myself wondering whether we should just make
>>> CHPL_TARGET_PLATFORM more
>>> specific in cases where we want it to be more specific. I.e., should
>>> we use
>>> 'linux64' as a means of saying "create a portable linux64 binary" (what
>>> we do
>>> today) and 'core-avx2-linux64' as a means of saying "create a linux64
>>> binary
>>> that's customized to core-avx2?" We could either require users to set
>>> these
>>> more stringent choices when they want better performance (which seems
>>> safe,
>>> but a little too bad), or we could beef up the chplenv/ scripts that
>>> auto-infer CHPL_*_PLATFORM to try to make them auto-select a more
>>> focused
>>> target than they do today (which would be challenging in the
>>> open-source
>>> cross-compilation environment... but cross-compilation is tricky in the
>>> open-source case in general...).
>>>
>>> Upside: Uses an existing environment variable? What else?
>>> Downside: Would need to tease multiple pieces of information out of one
>>> environment variable? What else?
>>>
>>> If we were to create new variables, I think CHPL_TARGET_ARCH or
>>> CHPL_TARGET_PROC is better than CHPL_RT_ARCH (and note that we could
>>> support
>>> the equivalent CHPL_HOST_* setting for symmetry, if one wanted to
>>> create a
>>> compiler that was potentially optimized to the host processor
>>> architecture).
>>>
>>>
>>> -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
