llvm dev - Feb 2009 - [LLVMdev] warning from -instcombine

On Feb 27, 2009, at 10:37 AM, Evan Cheng wrote:
>
> On Feb 27, 2009, at 1:47 AM, Jay Foad wrote:
>
>> Hi,
>>
>> I noticed this code in lib/Transforms/Scalar/ 
>> InstructionCombining.cpp:
>>
>>     cerr << "WARNING: While resolving call to function
'"
>>          << Callee->getName() << "' arguments
were dropped!\n";
>>
>> If you're using LLVM as a static compiler, this warning is a bit
>> incongruous, because it's not formatted in the same way as warnings
>> from the front end, and it isn't suppressed by -w.
>>
>> If you're using LLVM as a JIT, it seems completely wrong for any
>> optimisation pass to use cerr like this.
>>
>> So should it be removed, or downgraded to DOUT, or something?
>
> We should not remove them. These indicate a bug in the source,
> frontend, or earlier optimization passes. It's pretty useful.
Why not use assert() like mechanism to catch such bugs?
> It would
> be nice to have a backend diagnosis facility then we can control them.
> Patches welcome.
>
> Evan
>
>>
>>
>> There are a few other instances of cerr << "WARNING:
..." in other
>> LLVM passes.
>>
>> Thanks,
>> Jay.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-
Devang

On Feb 27, 2009, at 10:50 AM, Devang Patel wrote:
>>> So should it be removed, or downgraded to DOUT, or something?
>>
>> We should not remove them. These indicate a bug in the source,
>> frontend, or earlier optimization passes. It's pretty useful.
>
> Why not use assert() like mechanism to catch such bugs?
The compiler should not crash on invalid or poorly formed code.

-Chris

On 2009-02-27 21:33, Chris Lattner wrote:
> On Feb 27, 2009, at 10:50 AM, Devang Patel wrote:
>
>   
>>>> So should it be removed, or downgraded to DOUT, or something?
>>>>         
>>> We should not remove them. These indicate a bug in the source,
>>> frontend, or earlier optimization passes. It's pretty useful.
>>>       
>> Why not use assert() like mechanism to catch such bugs?
>>     
>
> The compiler should not crash on invalid or poorly formed code.
How about setting an error flag, and error message in the Module, then
let the caller know the Module is broken?
Sort of like what should happen on invalid inline assembly  instead of
abort(), as we already talked about.

Best regards,
--Edwin