Page MenuHomePhabricator

Port some floating point options to new option marshalling infrastructure
Needs ReviewPublic

Authored by dang on Mon, Jun 29, 4:02 AM.

Details

Summary

This changes cc1 semantics for some options such as -cl-fast-relaxed-math that implied other options. Now the driver always emits all the implied options, and each option maps to one key path in CompilerInvocation so that the new option parsing system can be used.

Diff Detail

Event Timeline

dang created this revision.Mon, Jun 29, 4:02 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald Transcript
jdoerfert resigned from this revision.Mon, Jun 29, 5:11 PM
Anastasia added inline comments.Wed, Jul 8, 6:31 AM
clang/include/clang/Driver/Options.td
1176

could this also be OptInFFlag?

clang/lib/Driver/ToolChains/Clang.cpp
2805

Is this a bug fix ?

clang/test/CodeGen/fp-function-attrs.cpp
2

Not clear why do you need to pass these extra flags now?

dang added inline comments.Thu, Jul 9, 2:21 AM
clang/include/clang/Driver/Options.td
1176

The aim was to keep the driver semantics the same as before and this was not something you could control with the driver, so I left it as just a CC1 flag. However if it makes sense to be able to control this from the driver then we can definitely make this OptInFFLag.

clang/lib/Driver/ToolChains/Clang.cpp
2805

No, in current trunk approximating floating point functions was something that was implied by other optimization flags, i.e. disabling math errno, enabling associative/reciprocal math, disabling signed zeros and disabling trapping math and -ffast-math which does all the previously mentioned things. This patch moves this logic in the driver by introducing a new CC1 flag for this so that parsing CC1 options can be more easily automated. This just reflects the logic that was previously inside cc1.

clang/test/CodeGen/fp-function-attrs.cpp
2

Previously passing -ffast-math to CC1 implied all these other flags. I am trying to make CC1 option parsing as simple as possible, so that we can then make it easy to generate a command line from a CompilerInvocation instance. You can refer to http://lists.llvm.org/pipermail/cfe-dev/2020-May/065421.html for more details on why we want to be able to do this