> On Fri, Nov 01, 2024 at 01:34:45PM +0100, Jan Hubicka wrote: > > > > > > malloc(SIZE_MAX / 2 + 1) does not succeed. > > > > Is malloc required to return NULL for block of half of address size or > > it is glibc behavior? Some time ago we was discussing possibility to > > I don't see C23 saying that explicitly (though it e.g. says that > calloc is guaranteed to return NULL if nmemb * size computation wraps around), > but I think it is derived from the fact that on objects larger than half > of the address space one can't (at least on arches where > ptrdiff_t/size_t/void * have the same precision) perform correct pointer > arithmetics. > > So, I think for calloc-like functions we need to be careful. > > Or we could just use the ranger and do this only if the size is known > from value ranges not to be larger than half of the address space and > for calloc-like that there is no overflow?
I think it can be implemented with some care. When the propagation hits if (malloc_retval != NULL) I can look up the corresponding size parameter of malloc, check with ranger if it is possibly too large, mark it live and produce the corresponding conditional for checking half of the size. It is some extra work, but doable. What is proper way to determine half of address space? > > > > Please reconsider? Why to we need to match LLVM here? > > > > Matching llvm is not really the goal. I implemented it since it is > > useful optimization for code that builds small objects on heap and > > compiler can optimize away their use. This is relatively common for > > code with higer abstraction penalty. My original motivation was > > std::vector and std::string consumers, but I think there is C code doing > > similar things, too, so it would be better to support both C and C++ > > allocations. > > Are most of such cases with variable sized allocations or fixed ones? In C++? I have no statistics, since we still did not concluded on __builtin_operator_new implementation so I have no easy way to test it. But I would expect std::vector/std::string to produce variably sized allocations, too. Honza > > Jakub >
