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

[Harald van Dijk via cfe-dev]

ping

On 27/08/2020 12:17, Harald van Dijk via cfe-dev wrote:
> Hi,
> 
> clang/lib/CodeGen/BackendUtil.cpp contains multiple checks for 
> attributes of LangOpts. The option processing that sets up LangOpts is 
> mostly done by ParseLangArgs, which is skipped for LLVM IR files. 
> Because of this, there are code generation differences when the 
> -save-temps command line option is used: that command line option causes 
> LLVM IR to be emitted to file and a new process to be spawned to process 
> that file, which does not process options the same way.
> 
> An example of this is
> 
>    typedef float __attribute__((ext_vector_type(2))) float2;
>    float2 foo (float2 a, float2 b, float2 c) {
>      return a * b + c;
>    }
> 
> This would generate different code with clang --target=mips 
> -mcpu=mips32r5 -mfp64 -mmsa -O3 -ffp-contract=fast depending on whether 
> -save-temps was also present, because the -ffp-contract=fast option 
> affects instruction selection but was ignored for LLVM IR input files.
> 
> While CompilerInvocation::CreateFromArgs contained special exceptions 
> for a few options that were handled by ParseLangArgs that also need to 
> be handled for LLVM IR, there are many more, and just allowing 
> ParseLangArgs to be called seems like the simpler fix.
> 
> I have created a patch for this and uploaded it as 
> <https://reviews.llvm.org/D86695> to get feedback. Does this look like a 
> good approach, or should instead the individual options that would have 
> an effect even for LLVM IR inputs continue to be listed in 
> CompilerInvocation::CreateFromArgs?
> 
> If the approach I took is a good one, how should -std=* options behave? 
> I decided to continue silently ignoring them for InputKind::Precompiled 
> as I feel it is reasonable to include them, but generate an error for 
> them for LLVM IR inputs as I feel it is unreasonable to include them. 
> Does that make sense too, or should they continue to be silently ignored 
> for LLVM IR inputs as well?
> 
> The patch I uploaded does not yet include tests as I am not sure what 
> sort of tests should be included. Would a test that the 
> -ffp-contract=fast option is now honored for LLVM IR input files 
> suffice, or should I find more options that were also previously 
> silently ignored, and figure out how to construct test cases for those too?
> 
> Cheers,
> Harald van Dijk