[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[mliska at suse dot cz]

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