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?
There are a few other instances of cerr << "WARNING: ..." in
other LLVM passes.
Thanks,
Jay.
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. 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
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 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.I agree that this sucks. :( Unfortunately, there is no really good solution for this right now. We do not have great location information in the LLVM IR unless debug info is around, so it is hard to produce decent diagnostics. OTOH, this specific warning is very useful, it can identify some serious issues that can only be detected at link-time. Edwin says:> 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.I agree. Giving optimizer/codegen a real diagnostics subsystem as Edwin proposes does sound like the right first step, even if it doesn't fix the "not having location info" problem. This would also handle the issues where the code generator will abort when presented with invalid inline asm, etc. If you were using a JIT you could recover from this instead of displaying it to the user. -Chris