[gmx-developers] warning Emulating FMA instructions - this is probably not what you want!

[Roland Schulz]

On Thu, Oct 18, 2012 at 11:32 AM, Szilárd Páll <szilard.pall at cbr.su.se>wrote:

>  On Thu, Oct 18, 2012 at 3:51 PM, Roland Schulz <roland at utk.edu> wrote:
>
>>
>>
>>  On Thu, Oct 18, 2012 at 9:19 AM, Szilárd Páll <szilard.pall at cbr.su.se>wrote:
>>
>>>   On Thu, Oct 18, 2012 at 3:12 PM, Roland Schulz <roland at utk.edu> wrote:
>>>
>>>>
>>>>
>>>>  On Thu, Oct 18, 2012 at 7:01 AM, Szilárd Páll <szilard.pall at cbr.su.se>wrote:
>>>>
>>>>> That's correct. The point I was trying to make is that we might end up
>>>>> hearing about this issue in the future if people use CFLAGS just by
>>>>> routine. I fact, I'm not even sure that cmake is not supposed to pick up
>>>>> CLAGS as well and it's some later cmake pass rewriting compiler options is
>>>>> that the current code is trying to overcome, but it ends up loosing some
>>>>> options when CFLAGS is set.
>>>>>
>>>>>  Any comments? Should CFLAGS work?
>>>>>
>>>>  Yes. And I think it mostly works like it
>>>> should. Environment variables should only be read the first time you run.
>>>> And it should overwrite any of the default settings. Thus I think we should
>>>> not set any flags if CFLAGS is set. Sander added that with 0ce2e62b72d2
>>>> to cmake/gmxCFlags.cmake. None of the flags set in that file are added to
>>>> CMAKE_C_FLAGS if CFLAGS is set.. But the new acceleration depending options
>>>> (e.g. -mavx) are set even if CFLAGS is set. I think this is wrong. If you
>>>> agree I can fix that.
>>>>
>>>
>>>   Wait a second, if you want to override all flags instead of
>>> appending, we might have to change the acceleration detection to drop all
>>> acceleration unless the flag that would be added is already in the CFLAGS
>>> passed. This sounds a bit awkward, but it's the only way to ensure that one
>>> does not end up e.g. with GMX_ACCELERATION=AVX_256, but no -mavx flag
>>> passed which will result in nasty compiler errors.
>>>
>>
>>  I think it is important to be consistent. I'm not sure there is a cmake
>> standard whether CFLAGS should overwrite or append flags. With autoconf we
>> used to overwrite and with gmxCFlags we overwrite. Given that, I don't
>> think it is a good idea to try to be too helpful. I think if the user
>> manually specifies something we shouldn't mess with it. Nothing is
>> more annoying than a program which does something else then explicitly
>> told. So if I call cmake with explicit set CFLAGS those exactly should be
>> used. If anything at all we should give a warning that those flags are
>> probably needed. If we want to have a different variable which means "add
>> those cflags to the default ones" that's fine. But I think based on the
>> history the meaning of CFLAGS is "use exactly those flags" and thus even
>> the acceleration flags shouldn't be added to it.
>>
>
>  Well, consistency in this case can be defined in many ways, but in
> principle I agree. However, by "consistent" you are referring to adherence
> to common *nix practices. At the same time, I was referring to prioritizing
> internal consistency, i.e. trying hard to not end up with broken
> configuration.Consequently, if we really want to stick hard "autoconf
> emulation" (assuming that the CMake behavior expected with CFLAGS is not
> documented to be the same as with autoconf), we need to *drop* all
> acceleration and probably disable other things (like the gcc 4.4 -O3
> bug workaround).
>
>  E.g. given a cmake invocation:
> $ CC=gcc CFLAGS="-foo -bar" cmake
> on a Sandy Bridge CPU, we should drop to GMX_ACCELERATION=SSE (because
> that's on by default with gcc).
>
>  Of course we can and should issue a warning, but especially if we won't
> have the configuration summary implemented for 4.6 (which based on the
> amount of volunteers is probable), a lot of warnings can go unnoticed in
> the 100-s of lines long CMake configuration output.
>

I don't think it makes any sense to automatic disable acceleration based on
flags. That is completely counter-intuitive and error prone. I think it is
completely normal that if one overwrites something that one can't expect it
to work anymore if one does it incorrectly. But maybe the user does it
on purpose. E.g. it is a gcc compiler wrapper which already has avx and so
on as flags anyhow. On the other hand the acceleration flags don't hurt if
they are appended twice. So the current approach is probably OK.

Roland

-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20121019/b8e68415/attachment.html>