[PATCH] D34753: [Support] - Add bad alloc error handler for handling allocation malfunctions

[Klaus Kretzschmar via Phabricator via llvm-commits]

kkretzsch abandoned this revision.
kkretzsch added a comment.

In https://reviews.llvm.org/D34753#799802, @MatzeB wrote:

> In general: This may warrant an RFC to llvm-dev to discuss the scope of these patches. I feel that making all of LLVM abort gracefully in out of memory situations will be hard/unmaintainable. I believe the trick would be to limit the scope. Remembering your EuroLLVM talk it seemed that you would only need IR construction in the long running server process so you can hand over that IR to shorter lived/restartable worker processes doing the actual code generation. So the scope may be limited to this use case avoiding the need to fix all the transformation passes to recover gracefully.


Yes, I agree limiting the scope is necessary and has to be discussed with the people. Howver, on short term we would like to start with small patches that fixes some obvious flaws, like exchanging mallocs by raw new operators as you suggest

>>! In https://reviews.llvm.org/D34753#799802, @MatzeB wrote:
>  Specifically about this patch: So a failing malloc would now call the handler, but a failing `new` would throw an exception (or more likely `abort()` in the default no-exceptions configuration of LLVM. Maybe we should rather: Use `new` instead of `malloc` wherever possible. I'm not sure why this particular code uses malloc at all? For the cases that still use `malloc` (only good reason I can think of would be using `realloc` later) maybe we can trigger the same C++ exception as a failing new?

Good idea. I'll run through our malloc patches and check where I can replace the mallocs . So a new bad alloc handler is not necessary anymore, so I'm closing this patch request.


https://reviews.llvm.org/D34753