[llvm-dev] PVS-Studio analysis of LLVM code

James Y Knight via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 3 16:32:01 PDT 2016


On Thu, Nov 3, 2016 at 12:23 PM, Yury Mikhaylov <yury.mikhaylov at gmail.com>
wrote:

> LLVM shouldn't replace new with new(std::nothrow), it should just abort.
>>
> Does it? When we were evaluating embedding LLVM a few years back, that was
> one of the major pain points for us. Something goes wrong and LLVM/Clang
> calls abort, crashing the whole program. Library shouldn't make these type
> of decisions lightly: return an error, throw an exception, fire up a smoke
> signal - whatever - but there's just not enough context to decide right at
> that level.
>

I agree you could make that argument for many of the places LLVM uses
assert() today. LLVM uses assert not just in checking invariants, but as an
error handling mechanism.

However, the level of extra complexity that would be required in order to
try to handle *memory allocation failure* is not worth it. Not even close
to worth it. There's only VERY limited classes of programs where that is a
worthwhile thing to try to do (example: PID 1). A compiler library isn't
one of them.

There's effectively zero chance the codebase will ever be able to recover
>> from OOMing, and with modern OSes, you're almost never going to actually
>> see a malloc failure until it's way too late, anyways.
>>
> IMO the best way is to allow user to specify their own allocation strategy
> with default fallback to std::new: JITs have bursts of activity between
> longer quiet periods and may want to defer memory cleanup until later; IDE
> with code completion may want to keep memory consumption in check and
> choose to disable whole feature, rather than impede other processes; and so
> on.
>

The global operator new is already overridable per the C++ standard. And,
malloc/free themselves are overridable, in practice, on common systems.
LLVM doesn't need to do anything special to allow users to plug in their
own allocator if they want to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/a2263bcd/attachment.html>


More information about the llvm-dev mailing list