https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968
--- Comment #5 from Martin Liška <mliska at suse dot cz> --- On 11/20/2014 11:43 PM, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968 > > Jan Hubicka <hubicka at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |hubicka at gcc dot gnu.org > > --- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> --- > /* If we wanted to, we could actually do a real increase by redeleting and > inserting. However, this would require O (log n) time. So just bail out > for now. */ > if (fibheap_comp_data (heap, key, data, node) > 0) > return NULL; > > It is clearly bug in the old implementation. Increase is quite easy to > handle: > you just remember the increased value and if your find_min returns one where > value has increased, just re-insert it and get another minimum. > > This requires to store two keys, that is probably not good for generic > template. Perhaps bb-reorder can just see if it is increasing and perform > delete+insert. Its loop is not perofrmance critical (inliner did so and it was > too slow in that case) > Hi. My suggested patch adds support for increase operation, where I delete and insert new key. As such usage is quite rare, I hope suggested approach fits? One can choose between: 'replace_key' and 'decrease', where the second one contains assert that new key is really smaller. Thanks, Martin
