Hi Momchil,
Thanks for looking into this!
Looking at the binaries (attached) text size has increased ...
$ size 456.hmmer-before.elf
textdata bss dec hex filename
1049603221 81752 189933 2e5ed ./456.hmmer-before.elf
$ size 456.hmmer-after.elf
textdata bss
Hi
On Tue, 29 Mar 2022 at 12:39, Maxim Kuvyrkov
wrote:
> Hi Momchil,
>
> Thanks for looking into this!
>
> Looking at the binaries (attached) text size has increased ...
>
> $ size 456.hmmer-before.elf
>textdata bss dec hex filename
> 1049603221 81752 189933 2e5ed .
Thinking a bit more about it, I reckon we can't just generally generally
entries in the
.eh_table if a function does not have CFI instructions as we'd need at least two
kinds of "empty" unwind info: one for frames where unwinding is no longer
possible,
and one where unwinding is done using just t
Hi Nikita,
Your patch seems to increase code-size of 401.bzip2 by 11% at -Oz. This is due
to BZ2_decompress() function growing by 56%.
Would you please investigate and see if this regression can be avoided?
Please let us know if you need help reproducing or analyzing the problem.
Regards,
--
> In that sense, creating .eh_frame entries for outlined functions is correct.
> However, if
> outlined functions do not contain CFI instructions, I think we can take the
> hit
> on the quality of the debugging information or the precision of profiling for
> the
> `-Oz` case only, for the benef
