--- Log opened Mon Jan 27 00:00:23 2020
03:02 -!- Terrance33Gorcza [~Terrance3@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]
03:06 -!- Gregg83Blanda [~Gregg83Bl@ns334669.ip-5-196-64.eu] has joined #bitcoin-builds
03:09 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds]
03:41 -!- jonatack [~jon@213.152.162.154] has joined #bitcoin-builds
06:08 -!- jonatack [~jon@213.152.162.154] has quit [Ping timeout: 265 seconds]
08:07 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-builds
08:24 -!- Gregg83Blanda [~Gregg83Bl@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 268 seconds]
10:45 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-builds
11:29 < dongcarl> fanquake elichai2 I see that there are a few toolchain flag PRs out there. I think we should just apply the proper ones to our Gitian/Guix builds, does that sound reasonable?
11:31 < dongcarl> elichai2: What were your interpretations of the bench results for your LTO PR?
11:31 < fanquake> dongcarl I'm not sure what you mean? Which ones are the "proper" ones
11:33 < dongcarl> fanquake: Talking about #17948 and #17929
11:34 < dongcarl> fanquake: Let me know if I'm misunderstanding anything
11:39 < fanquake> Right. Seems that was already the conclusion for 17948. If we don't apply the flags to depends as well we won't see the full benefits, but sure can just do gitian/Guix.
11:39 < fanquake> As for 17929, I was also planning on opening a PR for link time garbage collection (also not LTO), would that also be considered gitian/Guix only?
11:39 < fanquake> Do we need a new configure flag to group some of these optimisations?
11:39 < fanquake> Note that in the linker optimisation flags cases, there are linkers that already default to O1, just not GNU ld
11:39 < fanquake> dongcarl: also keen to get your time machine change in if you are happy with it, see my comments in that PR
11:44 < dongcarl> Perhaps the separation between "default" config flags and config flags that we supply to gitian/guix is: what is ~critical to the correct operation of the binary vs. what is the best binary we can produce reproducibly with our toolchain, what do you think?
11:48 < dongcarl> fanquake: I'm tidying up and documenting that right now, show have something merge-able tonight
11:48 < dongcarl> fanquake: just commented my matching hashes for that one
11:48 < fanquake> So mainly security/hardening flags. Does that mean you would want to drop something like dead_strip / dead_strip_dylibs from that group?
11:49 < fanquake> Obviously flags that are fixing compiler issues also critical.
11:50 < fanquake> I think dead_atrip is important security wise.
11:53 < dongcarl> Yeah I believe it's important security-wise, obviously we'll do case-by-case on future flags, but I do see how dead_strip* straddles the line a bit
11:55  * dongcarl also personally thinks that having functions/data/dylibs that are unreachable by the entry point or exported symbols can almost be seen as a linker bug
11:56 < dongcarl> Ah... Debug printing...
11:57 < fanquake> dongcarl: heh. You should also test the link time garbage collection when building for Linux/win and see how much gets stripped out. The saving in binary size is not insignificant
11:57 < fanquake> Maybe I'll open an rfc with sole stats first before any PRs
11:58 < dongcarl> Sounds good!
11:59 < fanquake> dongcarl: Could you also take a look at the build-id dmg PR of mine. That fixes an actual reproducibility issue we saw in rc1. Want to know if anyone else thinks it's worth eliminating.
12:02 < dongcarl> fanquake: Oh... native_libdmg-hfsplus wasn't reproducible? Or the DMGs it produced wasn't?
12:03 < fanquake> dongcarl the dmg tool wasn't reproducible, the build-id being embedded was different
12:03 < fanquake> I linked to the IRC that has the (short) discussion
12:04 < fanquake> Managed to run into an already found and fixed bug in diffoscope while investigating as well..
12:06 < dongcarl> fanquake: I see... And this is only a problem because we include the `dmg` binary in our unsigned tarball and compare them?
12:08 < fanquake> dongcarl yea. Jonas noticed the difference when putting together his detached sigs.
12:52 < elichai2> dongcarl: hmmm can't quite remember , I remember a decrease in binary size but don't remember other results. I can do a full IBD profile tomorrow
16:37 < fanquake> elichai2 interested in seeing those results
16:37 < fanquake> Will you be using full or thin LTO?
16:40 < elichai2> Good question
16:42 < elichai2> I guess the only meaningful upside of thin lto is compile times?
16:43 < fanquake> Potentially less performance gain for faster / less resource heavy builds
16:45 < fanquake> TO be honest it'd be worth just looking at both. Last time I did the compile times weren't that outrageous.
16:45 < fanquake> Just remember to make use of all your threads heh
16:46 < elichai2> I think I'll do fat lto, because if that doesn't give us performance gains then it's probably useless to also try thinlto
16:46 < elichai2> (Altough who knows)
16:46 < fanquake> I assume you'll be using Clang and lld?
16:47 < elichai2> Was just about to ask on clang VS gcc
16:48 < fanquake> I don't think I've used LTO with GCC at all. All my testing was with Clang 8 or 9.
22:41 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 260 seconds]
22:42 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-builds
--- Log closed Tue Jan 28 00:00:22 2020