[cfe-dev] [RFC] Call ParseLangArgs for all inputs

[Harald van Dijk via cfe-dev]

On 10/09/2020 22:37, Harald van Dijk via cfe-dev wrote:
> On 10/09/2020 21:51, Robinson, Paul wrote:
>> Moving them would be more typing, of course, but I suspect the original
>> reason ParseLangArgs isn't used on that path is that language-relevant
>> actions should already have been taken by the time we're reading IR 
>> back in.
> 
> This is true. That may be a misunderstanding of the intent of the 
> function, as the name can be read two ways: it can be read as processing 
> the options that are relevant for the language handling, and it can be 
> read as processing the options that are *only* relevant for the language 
> handling. The FP options are definitely relevant for the language 
> handling and later codegen both. The sanitizers I'm not sure about, they 
> are used during language handling, but I do not really know how they are 
> used during later codegen. I had thought it would not be worth the 
> effort to move the options, but if that would be the preferred route, I 
> can submit that as a patch instead. It would have to be limited to the 
> options where I can actually verify they affect codegen though, so it 
> may be less complete.

I tried to move this into CodeGenOpts as suggested but that does not 
work: the default FP contract mode is only the default FP contract mode, 
copied into FPOptions [1]. It can be overridden at the operator level 
with #pragma float_control(precise, on), which ends up calling 
setFPPreciseEnabled [2] to disallow FP contractions for individual 
operations. The codegen options are not available here, nor do I think 
they should they be.

The FP options information is well gone at instruction selection time. I 
think this means that the fact that MIPS uses this at instruction 
selection time is a bug that results in what looks like wrong code: 
fmadd is generated even when that pragma is specified. I now think it is 
correct that fp-contract is a language option, and it is a bug for 
targets to perform FP contraction themselves. Does that sound correct, 
or am I missing something about how this pragma is supposed to work?

If this is correct, I do not expect that simply removing this from the 
backends is going to be agreeable, as that is obviously going to hurt 
performance of code that does not use this pragma.

My primary concern is ensuring that -save-temps does not change the 
generated code, but it is now looking like there is no simple way to 
achieve that except with changes that are not good in the long run.

Cheers,
Harald van Dijk

[1]: https://clang.llvm.org/doxygen/LangOptions_8h_source.html#l00400
[2]: https://clang.llvm.org/doxygen/LangOptions_8h_source.html#l00483