[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

Jan Svoboda via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 23 08:02:21 PDT 2020


jansvoboda11 added a comment.

@dexonsmith, thanks for sharing your idea. Overall, I like the simplicity.

As you say, not every command line option has an associated `CodeGenOptions` or `LangOptions` field. For this patch only, we'd need to create the following fields:

- `CLUnsafeOptimizations` for `OPT_cl_unsafe_math_optimizations`
- `CLFiniteMathOnly` for `OPT_cl_finite_math_only`
- `CLNoSignedZeros` for `OPT_cl_no_signed_zeros`

I'm not sure how many other cases there are outside of what this patch touches.

Introducing ordering-sensitivity is not ideal, but if all options are defined in close proximity to each other, it should be relatively easy to reason about.

Correct me if I'm wrong, but when generating the command line, all "implied" flags would be hidden, even if they were explicit in the original comand line:

- original command line:  `clang -cc1 -cl-unsafe-math-optimizations -cl-mad-enable -menable-unsafe-fp-math -mreassociate -fno-signed-zeros -freciprocal-math -fapprox-func [...]`
- generated command line: `clang -cc1 -cl-unsafe-math-optimizations [...]`

This might be a bit surprising, but I don't think this would cause issues for explicit modules. What are your thoughts?

Formalizing the "implies" relationships would make it possible to remove the ordering-sensitivity and possibly generate implied flags even when explicitly passed to `cc1`. It would complicate the TableGen backend, which I'd prefer to keep as simple as possible.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82756/new/

https://reviews.llvm.org/D82756



More information about the llvm-commits mailing list