Binary size bloat in the last Nightly (Gnu64)

[leonardo-m]

In the current Nightly (gnu64 target) the sizes of the produced binaries has grown a lot (from 2017-08-27 to 2017-08-29 Nightlies).

The problem is visible in nightly-x86_64-pc-windows-gnu 1.21.0-nightly (c11f689 2017-08-29).

The test code is not critical, the problem is visible in all kinds of code, but you could use this:

https://gist.github.com/anonymous/324be5d846ea0a00cd2c5fed1ff747ea

See also:
https://users.rust-lang.org/t/std-library-inclusion-policy-and-a-data-point-of-compilation-times/5212/31

We have not yet tested the Gnu32 target.

(Also I've seen 15-20% decrease in performance of some binaries, but not for the tiny program above that runs in a moment).

[Mark-Simulacrum]

Nominating. Perhaps @arielb1 or @alexcrichton could do some preliminary investigation?

[alexcrichton]

Regression was introduced by #44107

Before that we're at e266888 and the program listed here generates a 1.3M executable, and after a0c3bd2 it generates a 2.9M executable. Probably debuginfo, I'll keep looking

[alexcrichton]

Ok I don't think this is a regression.

The previous configure script had an explicit clause to disable line debug information in nightlies due to a bug that was fixed long ago. The rewritten configure script is generating the debuginfo for the standard library on nightly like all other targets.

If you run strip -g the binaries have the same size.

As a result of that I'm going to close this. @leonardo-m if you've got a good test case for the performance please open a new bug though!

[leonardo-m]

if you've got a good test case for the performance please open a new bug though!

I have studied the situation, I think the reproducible performance difference is caused by very sensitive to tiny code changes workings of the LLVM optimization passes. Lot of time is spent in few tight loops, if the optimizes leaves or removes just few asm instructions in those, the performance of those programs of mine changes up to 20%. So no new bug report this time.