* Richard Biener:

>> Can you change this optimization so that it can use a fixed-size buffer?
>> This would avoid all issues around calling calloc.  If iter_count can be
>> very large, allocating that much extra memory might not be beneficial
>> anyway.
>
> It would need to be TLS storage though or protected against concurrent
> access (maybe an atomic is enough if we drop to the original loop when
> concurrent access is detected).

If it can be constrained to a small window, then it can be allocated on
the stack.

But I suspect the point of the optimization is to do this data
reorganization when huge amounts of temporary memory are needed.  I
don't see a way to make this safe in general.

glibc's qsort implementation does something quite similar manually,
including the extra memory allocations, and we occasionally receive
complaints about it.

Thanks,
Florian

Reply via email to