This is an archive of the discontinued LLVM Phabricator instance.

Add option to selectively disable the GVN pass.
AbandonedPublic

Authored by dim on May 27 2015, 1:12 PM.

Details

Summary

In FreeBSD, we are always having trouble getting one of our boot loaders
small enough, when compiled with clang/llvm. Each successive release of
clang has turned out to increase the size, and we had to enable all
kinds of llvm-only options to get the size below the target size.

With the 3.5.0 import though, we also had to add an option to
selectively disable the GVN pass. This shaved off yet another few bytes
of the resulting binary.

The patch lives here:
https://svnweb.freebsd.org/base/head/contrib/llvm/patches/patch-04-add-llvm-gvn-option.diff?revision=280031&view=markup

but I would rather have it upstream. Since this is a hidden option, and
the implementation is trivial, I don't think any particular test case is
necessary.

Diff Detail

Event Timeline

dim updated this revision to Diff 26628.May 27 2015, 1:12 PM
dim retitled this revision from to Add option to selectively disable the GVN pass..
dim updated this object.
dim edited the test plan for this revision. (Show Details)
dim added reviewers: chandlerc, hfinkel.
dim added a subscriber: emaste.
dim added a subscriber: Unknown Object (MLST).May 27 2015, 1:12 PM
hfinkel edited edge metadata.

I would much rather try to understand the problem. If GVN is doing something that tends to increase binary size even when compiling a function with the optsize attribute, then GVN should stop doing that. Have you provided a test case for this?

dim added a comment.May 28 2015, 12:04 AM

I would much rather try to understand the problem. If GVN is doing something that tends to increase binary size even when compiling a function with the optsize attribute, then GVN should stop doing that.

Sure, but at the moment we imported clang 3.5.0, this was our only showstopper, and we had to do a quick fix. We just experimented with enabling and disabling different passes, and ended up at this result.

Have you provided a test case for this?

I will dig this up later.

dim added a comment.May 29 2015, 12:02 PM

I originally posted D5859 for this, and a little overview in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141117/245549.html .

The test case (a preprocessed version of the second stage x86 bootloader for FreeBSD) is here: http://www.andric.com/freebsd/clang/boot2-minimal.c

We normally compile this with the following flags for clang versions earlier than 3.5.0:

clang -cc1 -triple i386-unknown-freebsd11.0 -emit-obj -mrelocation-model static -mregparm 3 -mrtd -target-cpu i386 -Os -w -ffreestanding -mstack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -mllvm -simplifycfg-dup-ret boot2-minimal.c

and for 3.5.0 and later, we use the -enable-gvn flag instead:

clang -cc1 -triple i386-unknown-freebsd11.0 -emit-obj -mrelocation-model static -mregparm 3 -mrtd -target-cpu i386 -Os -w -ffreestanding -mstack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -mllvm -enable-gvn=false boot2-minimal.c

Using clang 3.6.1, which is in FreeBSD 11-CURRENT at this time, I get the following results when I enable or disable the GVN pass:

text    data     bss     dec     hex filename
5466      12    4936   10414    28ae test-361-gvn-enabled.o
5447      12    4936   10395    289b test-361-gvn-disabled.o

E.g. it saves 19 bytes. I tried this again with clang trunk r238353, but there the results are the other way around:

text    data     bss     dec     hex filename
5359      12    4932   10303    283f test-trunk-gvn-enabled.o
5392      12    4932   10336    2860 test-trunk-gvn-disabled.o

So apparently the size optimizations work better now... I should probably put this review on hold, until I can test building the complete bootloader suite with a recent clang trunk snapshot.

dim abandoned this revision.Jan 27 2017, 1:04 PM

No longer really applicable. There have been substantial changes in size optimization.