Implement removal of malloc/free pairs with NULL check

Sam James sam@gentoo.org
Wed Nov 6 08:42:38 GMT 2024


Sam James <sam@gentoo.org> writes:

> Alexander Monakov <amonakov@ispras.ru> writes:
>
>> On Fri, 1 Nov 2024, Jan Hubicka wrote:
>>
>>> > I have a vague memory that one of the tests in SPEC has a loop that
>>> > tries to malloc, doubling the size each time, until it fails.  Would
>>> > the patch change the behavior of such a loop?
>>> 
>>> If the resulting allocation is unused except for NULL check we will make
>>> it always "succeed" and thus the loop will likely loop forever.  I
>>> wonder what this loop computes on systems, like linux, that overcommits
>>> memory.
>>
>> Even with overcommit, malloc is going to return NULL as soon as you pass
>> a half or more of the address space as the requested allocation size.
>>
>> Since the patch eliminates malloc with unknown size, I think this transform
>> is incorrect (wasn't correct for the same reason in LLVM either).
>>
>> I'm pretty sure it's going to break some Glibc tests that verify that
>> malloc(SIZE_MAX / 2 + 1) does not succeed.
>>
>> Please reconsider? Why to we need to match LLVM here?
>
> Some references to feed discussion which I had in my logs from
> discussing it with someone the other week after that interaction we
> had with alanc:
> * https://github.com/llvm/llvm-project/issues/28790 (not very
> insightful, other than to show it has a history of confusing people, but
> one might argue that for other (definitely-valid) optimisations)
> * https://github.com/llvm/llvm-project/issues/49826
> * https://github.com/llvm/llvm-project/issues/51476

+ https://github.com/llvm/llvm-project/issues/114772




More information about the Gcc-patches mailing list