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

[Harald van Dijk via cfe-dev]

ping 2

On 03/09/2020 12:24, Harald van Dijk via cfe-dev wrote:
> 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