Re: The case of LTO when produced enlarged binaries
On Mon, 2020-08-31 at 09:17 +0200, Bob Mauchin wrote: > > > On Mon, Aug 31, 2020, 05:32 Jeff Law wrote: > > On Sun, 2020-08-30 at 14:42 +0200, Igor Raits wrote: > > > On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > > > > On Fri, 24 Jul 2020 at 21:31, Igor Raits < > > > > ignatenkobr...@fedoraproject.org> > > > > wrote: > > > > [..] > > > > > > > > > Well, I tell what I see :) > > > > > > > > > > Compiling kitty with settings below produces this big > > > > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > > > > > > > * Without any LTO-related flags: 4.52 MB > > > > > * With -flto: 4.30 MB > > > > > * With -flto -ffat-lto-objects: 4.79 MB > > > > > > > > > > Well, I did not run compilation multiple times but don't think it > > > > > will > > > > > change much. > > > > > > > > > > > > > Comparing the size of the executable files does not make any sense. > > > > You should use the "size" command. > > > > > > Well, I'd use `size` command if I would care what section of a file > > > takes what size. In this case, I don't really care which section it is. > > > > > > All I care is that with -ffat-lto-objects, binary becomes bigger. > > Given this isn't a correctness issue, I haven't prioritized it. > > > > A quick look tells me all the difference is in the symbol table -- ie, the > > code, > > data and bss sections are the same size, but the symbol table is > > significantly > > larger. And AFAICT it's all debug symbols. > > > > In fact, it doesn't look like the debug info was stripped at all: > > > > [law@localhost kitty]$ objdump -h fast_data_types.so > > > > fast_data_types.so: file format elf64-x86-64 > > [ ... ] > > 26 .debug_aranges 01e0 000e2b64 > > 2**0 > > CONTENTS, READONLY, DEBUGGING, OCTETS > > 27 .debug_info 000e60c7 000e2d44 > > 2**0 > > CONTENTS, READONLY, DEBUGGING, OCTETS > > 28 .debug_abbrev 7543 001c8e0b > > 2**0 > > CONTENTS, READONLY, DEBUGGING, OCTETS > > 29 .debug_line 0007644f 001d034e > > 2**0 > > CONTENTS, READONLY, DEBUGGING, OCTETS > > 30 .debug_str0005cab8 0024679d > > 2**0 > > CONTENTS, READONLY, DEBUGGING, OCTETS > > 31 .debug_loc000d6477 002a3255 > > 2**0 > > CONTENTS, READONLY, DEBUGGING, OCTETS > > 32 .debug_ranges 0003a000 003796cc > > 2**0 > > CONTENTS, READONLY, DEBUGGING, OCTETS > > 33 .debug_macro 0002b64f 003b36cc > > 2**0 > > CONTENTS, READONLY, DEBUGGING, OCTETS > > > > > > So someone needs to figure out why debug symbols aren't being stripped. I > > manually stripped the bits in kitty and after doing so the sizes of the > > resultant > > DSOs are the same (as I'd expect them to be) across the two builds. > > > > jeff > > Is the file permission 0755? This is often a permission problem I encounter > while reviewing. It is, but I'm not sure that's the core issue. brp-strip explictly filters out DSOs, so it won't strip the .so files. We have brp-strip-shared, but its never called AFAICT. I'm not sure what folks want to do here, but it's clearly broken and really doesn't have anything to do with LTO. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
On Mon, Aug 31, 2020, 05:32 Jeff Law wrote: > On Sun, 2020-08-30 at 14:42 +0200, Igor Raits wrote: > > On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > > > On Fri, 24 Jul 2020 at 21:31, Igor Raits < > > > ignatenkobr...@fedoraproject.org> > > > wrote: > > > [..] > > > > > > > Well, I tell what I see :) > > > > > > > > Compiling kitty with settings below produces this big > > > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > > > > > * Without any LTO-related flags: 4.52 MB > > > > * With -flto: 4.30 MB > > > > * With -flto -ffat-lto-objects: 4.79 MB > > > > > > > > Well, I did not run compilation multiple times but don't think it > > > > will > > > > change much. > > > > > > > > > > Comparing the size of the executable files does not make any sense. > > > You should use the "size" command. > > > > Well, I'd use `size` command if I would care what section of a file > > takes what size. In this case, I don't really care which section it is. > > > > All I care is that with -ffat-lto-objects, binary becomes bigger. > Given this isn't a correctness issue, I haven't prioritized it. > > A quick look tells me all the difference is in the symbol table -- ie, the > code, > data and bss sections are the same size, but the symbol table is > significantly > larger. And AFAICT it's all debug symbols. > > In fact, it doesn't look like the debug info was stripped at all: > > [law@localhost kitty]$ objdump -h fast_data_types.so > > fast_data_types.so: file format elf64-x86-64 > [ ... ] > 26 .debug_aranges 01e0 000e2b64 > 2**0 > CONTENTS, READONLY, DEBUGGING, OCTETS > 27 .debug_info 000e60c7 000e2d44 > 2**0 > CONTENTS, READONLY, DEBUGGING, OCTETS > 28 .debug_abbrev 7543 001c8e0b > 2**0 > CONTENTS, READONLY, DEBUGGING, OCTETS > 29 .debug_line 0007644f 001d034e > 2**0 > CONTENTS, READONLY, DEBUGGING, OCTETS > 30 .debug_str0005cab8 0024679d > 2**0 > CONTENTS, READONLY, DEBUGGING, OCTETS > 31 .debug_loc000d6477 002a3255 > 2**0 > CONTENTS, READONLY, DEBUGGING, OCTETS > 32 .debug_ranges 0003a000 003796cc > 2**0 > CONTENTS, READONLY, DEBUGGING, OCTETS > 33 .debug_macro 0002b64f 003b36cc > 2**0 > CONTENTS, READONLY, DEBUGGING, OCTETS > > > So someone needs to figure out why debug symbols aren't being stripped. I > manually stripped the bits in kitty and after doing so the sizes of the > resultant > DSOs are the same (as I'd expect them to be) across the two builds. > > jeff > Is the file permission 0755? This is often a permission problem I encounter while reviewing. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
On Sun, 2020-08-30 at 14:42 +0200, Igor Raits wrote: > On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > > On Fri, 24 Jul 2020 at 21:31, Igor Raits < > > ignatenkobr...@fedoraproject.org> > > wrote: > > [..] > > > > > Well, I tell what I see :) > > > > > > Compiling kitty with settings below produces this big > > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > > > * Without any LTO-related flags: 4.52 MB > > > * With -flto: 4.30 MB > > > * With -flto -ffat-lto-objects: 4.79 MB > > > > > > Well, I did not run compilation multiple times but don't think it > > > will > > > change much. > > > > > > > Comparing the size of the executable files does not make any sense. > > You should use the "size" command. > > Well, I'd use `size` command if I would care what section of a file > takes what size. In this case, I don't really care which section it is. > > All I care is that with -ffat-lto-objects, binary becomes bigger. Given this isn't a correctness issue, I haven't prioritized it. A quick look tells me all the difference is in the symbol table -- ie, the code, data and bss sections are the same size, but the symbol table is significantly larger. And AFAICT it's all debug symbols. In fact, it doesn't look like the debug info was stripped at all: [law@localhost kitty]$ objdump -h fast_data_types.so fast_data_types.so: file format elf64-x86-64 [ ... ] 26 .debug_aranges 01e0 000e2b64 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 27 .debug_info 000e60c7 000e2d44 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 28 .debug_abbrev 7543 001c8e0b 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 29 .debug_line 0007644f 001d034e 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 30 .debug_str0005cab8 0024679d 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 31 .debug_loc000d6477 002a3255 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 32 .debug_ranges 0003a000 003796cc 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 33 .debug_macro 0002b64f 003b36cc 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS So someone needs to figure out why debug symbols aren't being stripped. I manually stripped the bits in kitty and after doing so the sizes of the resultant DSOs are the same (as I'd expect them to be) across the two builds. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > On Fri, 24 Jul 2020 at 21:31, Igor Raits < > ignatenkobr...@fedoraproject.org> > wrote: > [..] > > > Well, I tell what I see :) > > > > Compiling kitty with settings below produces this big > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > * Without any LTO-related flags: 4.52 MB > > * With -flto: 4.30 MB > > * With -flto -ffat-lto-objects: 4.79 MB > > > > Well, I did not run compilation multiple times but don't think it > > will > > change much. > > > > Comparing the size of the executable files does not make any sense. > You should use the "size" command. Well, I'd use `size` command if I would care what section of a file takes what size. In this case, I don't really care which section it is. All I care is that with -ffat-lto-objects, binary becomes bigger. > kloczek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9LnrEACgkQEV1auJxc Hh53yw//cmMnlkGgq0/BiSIv3SOAPhB786QkhnIGx9QhntOx/6akOFyxp4Td5xDB tb/tpoTaZUoDS0FMT03Q2+BVEC6aYnLU3Q/g8gSYrNi+Oyscd8PMztIS+XVnrAhy kb21ZrEkbhVP+tLGNqtpOjvBdkG6lEttDUAZLx2KGl8xBA+qcTWdnt2ZyvkYjQyj rNYM+yvN08phsk8JpEeb8yNwTzfy5FaPx+/TrFhNzCRgx68ttWckEfJqLn0RqIfU bdDw/pVYTW9WmZDzq8kBuBS3t1k/hs2/Jdyqs3NlfXIjBe4BaSJ17JqdwZIUaKnC c4m3Npl/U2ENJ8wHGNkZPF8BcJK29PlXU8BGGrfRADIzs2JjnFDHC6kuxScybfKI Reyhhp70U3mMWeuzoHvZO1hOW88gzqAVbO8bQWYzDzLGEim0Uwa738BuMIZeh5tN hJ2flGM2vve7u1jXNvdis/8WidkptPObis6egH82hoTtmp4KWhjKVEgU6NK9AYpI NurwZzdiMrYXdP0D9iAEYvTWuivi8nYIBLJ3P3AZGYKn+O790Mbv97emrSgxQdrf rK6KsIUbH+ggR+k91YoT1iZaITjrGKaQOb/YAfOytkxBXMK5B/xZ0dpnzUXBHdy+ OgJfeUx9rlrYwVUUpn2KxZSbM+KgF4/mWIgg/fyREoZYuMHeVuo= =sRls -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
On Fri, 24 Jul 2020 at 21:31, Igor Raits wrote: [..] > Well, I tell what I see :) > > Compiling kitty with settings below produces this big > /usr/lib64/kitty/kitty/fast_data_types.so: > > * Without any LTO-related flags: 4.52 MB > * With -flto: 4.30 MB > * With -flto -ffat-lto-objects: 4.79 MB > > Well, I did not run compilation multiple times but don't think it will > change much. > Comparing the size of the executable files does not make any sense. You should use the "size" command. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 14:32 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 22:30 +0200, Igor Raits wrote: > > On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote: > > > On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote: > > > > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > > > > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > > > > > Hi. In rare cases building packages with LTO producing > > > > > > binaries > > > > > > or > > > > > > libraries which have bigger size then if they have built > > > > > > without > > > > > > LTO. For example 'kitty' package: > > > > > > > > > > > > * with LTO: > > > > > > - koji task > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > > > > > 1.79 MB glfw-wayland.so > > > > > > 1.99 MB glfw-x11.so > > > > > > 4.78 MB fast_data_types.so > > > > > > 8.56 MB total > > > > > > > > > > > > * no LTO > > > > > > - koji > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > > > > > 1.65 MB glfw-wayland.so > > > > > > 1.84 MB glfw-x11.so > > > > > > 4.51 MB fast_data_types.so > > > > > > 8.00 MB total > > > > > > > > > > > > Difference is 7%. What we should do in such case? Should we > > > > > > disable > > > > > > LTO for such packages? Or there is still could be gains > > > > > > from > > > > > > faster > > > > > > code execution speed? > > > > > I'd tend to leave LTO on, but it's totally your call. > > > > > Without > > > > > looking at the > > > > > binaries, sources and compiler dumps I'd hazard a guess > > > > > you're > > > > > getting a lot of > > > > > cross module inlining, but very little identical code > > > > > folding. > > > > > THe > > > > > former tends > > > > > to make things bigger, but faster. The latter tends to > > > > > shrink > > > > > code > > > > > with little > > > > > impact on runtime performance. > > > > > > > > From what I see in this case, -ffat-lto-objects generates code > > > > that > > > > is > > > > bigger than without -flto. -flto alone generates smaller code > > > > than > > > > without -flto. > > > The fat-lto-objects bits are not used during an LTO link. They > > > exist > > > solely to > > > cover the case where there's a .o/.a that ends up installed. > > > > Well, I tell what I see :) > > > > Compiling kitty with settings below produces this big > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > * Without any LTO-related flags: 4.52 MB > > * With -flto: 4.30 MB > > * With -flto -ffat-lto-objects: 4.79 MB > > > > Well, I did not run compilation multiple times but don't think it > > will > > change much. > That's quite bizarre. I'll put it on the list of things to > investigate. Hi Jeff, Any news about this issue? > jeff > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9Li60ACgkQEV1auJxc Hh4q4A/6AyqFOE64rYb6gdhdlqJWKZovmucbeXMnpq6wD0zUqrpvaUyyAaSjGQ6D tLs+7RC8rFqErfPDUsnSll90+HiHqHRp1O6UOLjRQ8EwbSVZGQ0e0l5NfrktRy8i mjMG1r7KrKbuRQi3/4//lg8PQroVvXLqNIuwSpLYiDYA3loJAra0+pdP2mSdiWpk zAn8uAx5wOLNmWKqv+OS6SU3oiJXAOezBgDSoF70fgxAep7qgv6J+wjLrtkl2U1G 3atZ2r7+pfvI5UiFp9/0CXT0ZW9SQRoXMza0OURZpvUIk21f0nYjQgXv4gEWttf/ 7hOO4n+tg3xqurgb91j7WW9VNEiMbACYTidv/jxhAqOwBj6jeozh5e0YrmsRZ3Oa ZN74SWXl9k2Omh8By3EaNappHCLO9Oxr0DTkt+hc2JNTtmc9m5SPYnl4nd+N80wd iqv1Cg9wG46cL+Ofnz+L03F7rzsXN0ywwoKOZMGwkPsGrmOFcxko4iJ4j7tzUCiz K0iJFqeYoh6oPRGomZ1+KZP+mlKGaV9GZ0FhdIhCOB0MV0Yshk+4TdW5OQ5sYsby YLL12yN/WKCRsm16XH1bT8hu8Qu56bued0HOn9PrYDqz4txa2+d6QdOLUFTATiOY QfWO+31o236UkWSjxc+Wc34KHox5vr+ueNrnDUaKtwOc7jpqvJ0= =zrRd -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
On Fri, 2020-07-24 at 22:30 +0200, Igor Raits wrote: > On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote: > > On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote: > > > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > > > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > > > > Hi. In rare cases building packages with LTO producing binaries > > > > > or > > > > > libraries which have bigger size then if they have built > > > > > without > > > > > LTO. For example 'kitty' package: > > > > > > > > > > * with LTO: > > > > > - koji task > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > > > > 1.79 MB glfw-wayland.so > > > > > 1.99 MB glfw-x11.so > > > > > 4.78 MB fast_data_types.so > > > > > 8.56 MB total > > > > > > > > > > * no LTO > > > > > - koji > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > > > > 1.65 MB glfw-wayland.so > > > > > 1.84 MB glfw-x11.so > > > > > 4.51 MB fast_data_types.so > > > > > 8.00 MB total > > > > > > > > > > Difference is 7%. What we should do in such case? Should we > > > > > disable > > > > > LTO for such packages? Or there is still could be gains from > > > > > faster > > > > > code execution speed? > > > > I'd tend to leave LTO on, but it's totally your call. Without > > > > looking at the > > > > binaries, sources and compiler dumps I'd hazard a guess you're > > > > getting a lot of > > > > cross module inlining, but very little identical code folding. > > > > THe > > > > former tends > > > > to make things bigger, but faster. The latter tends to shrink > > > > code > > > > with little > > > > impact on runtime performance. > > > > > > From what I see in this case, -ffat-lto-objects generates code that > > > is > > > bigger than without -flto. -flto alone generates smaller code than > > > without -flto. > > The fat-lto-objects bits are not used during an LTO link. They exist > > solely to > > cover the case where there's a .o/.a that ends up installed. > > Well, I tell what I see :) > > Compiling kitty with settings below produces this big > /usr/lib64/kitty/kitty/fast_data_types.so: > > * Without any LTO-related flags: 4.52 MB > * With -flto: 4.30 MB > * With -flto -ffat-lto-objects: 4.79 MB > > Well, I did not run compilation multiple times but don't think it will > change much. That's quite bizarre. I'll put it on the list of things to investigate. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote: > > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > > > Hi. In rare cases building packages with LTO producing binaries > > > > or > > > > libraries which have bigger size then if they have built > > > > without > > > > LTO. For example 'kitty' package: > > > > > > > > * with LTO: > > > > - koji task > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > > > 1.79 MB glfw-wayland.so > > > > 1.99 MB glfw-x11.so > > > > 4.78 MB fast_data_types.so > > > > 8.56 MB total > > > > > > > > * no LTO > > > > - koji > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > > > 1.65 MB glfw-wayland.so > > > > 1.84 MB glfw-x11.so > > > > 4.51 MB fast_data_types.so > > > > 8.00 MB total > > > > > > > > Difference is 7%. What we should do in such case? Should we > > > > disable > > > > LTO for such packages? Or there is still could be gains from > > > > faster > > > > code execution speed? > > > I'd tend to leave LTO on, but it's totally your call. Without > > > looking at the > > > binaries, sources and compiler dumps I'd hazard a guess you're > > > getting a lot of > > > cross module inlining, but very little identical code folding. > > > THe > > > former tends > > > to make things bigger, but faster. The latter tends to shrink > > > code > > > with little > > > impact on runtime performance. > > > > From what I see in this case, -ffat-lto-objects generates code that > > is > > bigger than without -flto. -flto alone generates smaller code than > > without -flto. > The fat-lto-objects bits are not used during an LTO link. They exist > solely to > cover the case where there's a .o/.a that ends up installed. Well, I tell what I see :) Compiling kitty with settings below produces this big /usr/lib64/kitty/kitty/fast_data_types.so: * Without any LTO-related flags: 4.52 MB * With -flto: 4.30 MB * With -flto -ffat-lto-objects: 4.79 MB Well, I did not run compilation multiple times but don't think it will change much. > jeff > > > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8bROYACgkQEV1auJxc Hh6dsBAApNegXihpiJ3SVr5IiD4pypEUDUNyBTY+Tp+HINNWdQHVivs2jYWwfVpU rNokkpq6Crgj68wznNGnwq+/eSP7DQwP3rN0TsAsfVydO1w0xBkz3zC47Y/7NPRR Ceeoalajz6/EqN89LDyYT/aQbfT4zbOV0ZTnUQrOe21URg2L1mUBSjeCoDortkC+ 1um7lyexAFroXmU4fQSdUMNTLrSolfFJPlkqeaaiJorqMvzex08xrv1D3vRrIyBD 6Z0NdPjB1nMbIWdCwTATYkbARzBH/88AUE3RZbjvRakr1BTBmsye3XaFts3Gn4Q8 ykINe/ImL+sDxm+cxKEAzafnr2GZQPvxYbwPjF+CEwDsBhqn92goOewgrrxNh+sq e9yf0vpJhmJBIq/hwPgvTihn9vB7oqxjT2/CFjIlNFCc5FyZfuSJPsyE/8EA4Vb6 9b8vj/q+gAlt9Ty/aJ+yhxQsO8zT0ZrVOi4L1/5RQna9HGca3YyKH4v9exHRMSpo HtbacKKg+7zYvVif7go6ERGBM680Pi5t6ypaH2cWOg4lRX50BVNn5NDpvatnOD/L VxJ1p+LmhRaoXT1Kzb4P5bNaSl+o7lPAjIjRk8osVll7m2jxFJxKfMLvnUBUaROj 5mVGA2JgdgGXKOdeFLHPsDmxs9B+EdR+PMzhMkcbww+MbhPXOiM= =gRTO -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote: > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > > Hi. In rare cases building packages with LTO producing binaries or > > > libraries which have bigger size then if they have built without > > > LTO. For example 'kitty' package: > > > > > > * with LTO: > > > - koji task > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > > 1.79 MB glfw-wayland.so > > > 1.99 MB glfw-x11.so > > > 4.78 MB fast_data_types.so > > > 8.56 MB total > > > > > > * no LTO > > > - koji > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > > 1.65 MB glfw-wayland.so > > > 1.84 MB glfw-x11.so > > > 4.51 MB fast_data_types.so > > > 8.00 MB total > > > > > > Difference is 7%. What we should do in such case? Should we disable > > > LTO for such packages? Or there is still could be gains from faster > > > code execution speed? > > I'd tend to leave LTO on, but it's totally your call. Without > > looking at the > > binaries, sources and compiler dumps I'd hazard a guess you're > > getting a lot of > > cross module inlining, but very little identical code folding. THe > > former tends > > to make things bigger, but faster. The latter tends to shrink code > > with little > > impact on runtime performance. > > From what I see in this case, -ffat-lto-objects generates code that is > bigger than without -flto. -flto alone generates smaller code than > without -flto. The fat-lto-objects bits are not used during an LTO link. They exist solely to cover the case where there's a .o/.a that ends up installed. jeff > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > Hi. In rare cases building packages with LTO producing binaries or > > libraries which have bigger size then if they have built without > > LTO. For example 'kitty' package: > > > > * with LTO: > > - koji task > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > 1.79 MB glfw-wayland.so > > 1.99 MB glfw-x11.so > > 4.78 MB fast_data_types.so > > 8.56 MB total > > > > * no LTO > > - koji > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > 1.65 MB glfw-wayland.so > > 1.84 MB glfw-x11.so > > 4.51 MB fast_data_types.so > > 8.00 MB total > > > > Difference is 7%. What we should do in such case? Should we disable > > LTO for such packages? Or there is still could be gains from faster > > code execution speed? > I'd tend to leave LTO on, but it's totally your call. Without > looking at the > binaries, sources and compiler dumps I'd hazard a guess you're > getting a lot of > cross module inlining, but very little identical code folding. THe > former tends > to make things bigger, but faster. The latter tends to shrink code > with little > impact on runtime performance. - From what I see in this case, -ffat-lto-objects generates code that is bigger than without -flto. -flto alone generates smaller code than without -flto. > Unfortunately comparing this stuff in an LTO world is much harder > than in a non- > LTO world. You can't just bisect it to a .o or function that's > larger :( > > > jeff > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl8bQ2cACgkQEV1auJxc Hh4KkA/+LfGfZGjkZZcgJfgRYhVGdjpFpjdEjwTPQh/75IFnkd0q0BAJlHAxuvKA HQ0z/EQH5dfXIXtKYzg8+t+EHYjABPio+BSllNtv8OOAFW55TsRgxHCq/vDDjugU gM9urFXTvYnK8P52/EFMmZoIcg0PiLEMDArsoeUmHxzBDLSi4755HAsz/dz0VWxa BpJWWavTDHSFgkjMbqsrU/E9n/N0WdRdhaG1vuYEc80OLuQxGA9wSyT8fCOauGGZ 6qg2l93gHmQQys/V1PDOup2Dpjgr/GFEN3H0Q55UhdszXhfYKmipA0gS+rX7evyH jj9bYN+VMm8Qq9i7wmwPHsa88kYztozsx3vXYebpnuxgzG0uq1F+A2WoxkECtztc n5Ug0wUbYZSEBbpzxt7Tr9zaYoJ+TzdT8Ce+doub+P2fmnGO3Rhz87V0MGyiYcSG siBdnMBh26MwkQxRJkb5oR7WwCDmde2Rt7SmkVQuBI4sIUN418tif+bJUV+PMeMJ Q2hvqZryKeMHqGx7QmoUqSr5dMcZaY4zvMVbWggn2+qphNyI7gdc+QZMmtJ+5xeG ZpgKjMDofW8PWgD8Pn3ToeN/pyIzFFd17vvYY1sFD1ZpKE229T58eP6kWiMOnGyL j2/BI5UGjH0s+bhiUDLvfyVregBJRSxTptP975HLjjiP4GWUYN0= =taI4 -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > Hi. In rare cases building packages with LTO producing binaries or libraries > which have bigger size then if they have built without LTO. For example > 'kitty' package: > > * with LTO: > - koji task https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > 1.79 MB glfw-wayland.so > 1.99 MB glfw-x11.so > 4.78 MB fast_data_types.so > 8.56 MB total > > * no LTO > - koji https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > 1.65 MB glfw-wayland.so > 1.84 MB glfw-x11.so > 4.51 MB fast_data_types.so > 8.00 MB total > > Difference is 7%. What we should do in such case? Should we disable LTO for > such packages? Or there is still could be gains from faster code execution > speed? I'd tend to leave LTO on, but it's totally your call. Without looking at the binaries, sources and compiler dumps I'd hazard a guess you're getting a lot of cross module inlining, but very little identical code folding. THe former tends to make things bigger, but faster. The latter tends to shrink code with little impact on runtime performance. Unfortunately comparing this stuff in an LTO world is much harder than in a non- LTO world. You can't just bisect it to a .o or function that's larger :( jeff > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
The case of LTO when produced enlarged binaries
Hi. In rare cases building packages with LTO producing binaries or libraries which have bigger size then if they have built without LTO. For example 'kitty' package: * with LTO: - koji task https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 1.79 MB glfw-wayland.so 1.99 MB glfw-x11.so 4.78 MB fast_data_types.so 8.56 MB total * no LTO - koji https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 1.65 MB glfw-wayland.so 1.84 MB glfw-x11.so 4.51 MB fast_data_types.so 8.00 MB total Difference is 7%. What we should do in such case? Should we disable LTO for such packages? Or there is still could be gains from faster code execution speed? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
