* 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
