Date: Wed, 29 Mar 2017 23:42:00 -0700 From: "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Bruce Evans <brde@optusnet.com.au>, Poul-Henning Kamp <phk@phk.freebsd.dk>, John Baldwin <jhb@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r316132 - head/sys/boot/i386/boot2 Message-ID: <6B63C559-C48C-4824-9D24-87FF89336FE4@gmail.com> In-Reply-To: <CANCZdfpw19UUTSKjkM1qqpF_-or=c4EdMFoKnek6_cHZUhup=A@mail.gmail.com> References: <201703290930.v2T9U3x9087583@repo.freebsd.org> <7448826.asYms2TLO2@ralph.baldwin.cx> <46812.1490823365@critter.freebsd.dk> <CANCZdfr2eRRMQy-uwXDhxT0z88CBKwtkg2e_jFBOg%2Bs_L8=FYg@mail.gmail.com> <20170330165329.L1061@besplex.bde.org> <CANCZdfpw19UUTSKjkM1qqpF_-or=c4EdMFoKnek6_cHZUhup=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Mar 29, 2017, at 23:38, Warner Losh <imp@bsdimp.com> wrote: > > On Thu, Mar 30, 2017 at 12:23 AM, Bruce Evans <brde@optusnet.com.au> wrote: >> I doubt that gcc-6.3 is very broken. Did its CFLAGS even have -Os? > > Yes. boot2 doesn't use the kernel CFLAGS. > >> Kernel CFLAGS are still broken even for gcc-4.2, by sprinkling inline >> parameter magic that was more needed for gcc-3.3. The magic isn't >> really right for gcc-4.2, and breaks -Os for kernels. > > There is different magic for boot2. > >> The magic might >> be wronger for gcc-6.3, though it would be a compiler bug to not >> just ignore it if it is nonsense. clang doesn't provide any control >> over inlining AFAIK, but ignores gcc directive to limit it and does >> too much. > > Yes. It does. Hence my glowing review of 6.3 :) But you are right. I'm > likely being overly harsh without commanding enough facts to get past > my preconceived notions... I don't know if this is a simple compiler > bug, lack of proper options, or a need to do things differently. > Latter day versions of gcc have many more knobs to turn here. I don't > know yet if turning any of them will be helpful. I'm looking to > automate the knob turning so that we can at least see which optimizer > options have an effect on the size. I doubt more than half a dozen > have any useful effect on the size, and finding the right combination > likely will suffice. Or we wait for gcc 7 and hope for the best... > > But this is nothing new. gcc 5.4.0 has -504 bytes free. gcc 4.9.4 has > the same. 4.8.5 has -472, etc. It's clear that the magic sweet spot > we're in with the in-tree 4.2.1 compiler isn't the sweet spot for > these compilers... Then again, clang generated bloated like this until > we got boot2 into their test suit, and now we have 100 bytes to spare > there. I know that a handful of people (several years ago) spent a lot of time making clang work with boot2 and be under the limit. I’m not entirely sure, but we could have done similar things (but in more ominous ways in) gcc 4.2.1 to shrink down the boot loader. Just a thought >_>… -Ngie [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY3Ki5AAoJEPWDqSZpMIYVJPkQANXbiVVyuAjHwsxFBz3CYqJl uSjq5TEXru0fKZFv+IRxLQyx7GkBV+Bwgr4UhKs5/9ZAClq0QklUFpi2YnkrvZHN LUsXc7bYoJPGtQGwpvbezJHohMaBwGogky4hsH+KcsFvPltAqOdxUeM3W4JiaCcX c3iKsb8yGeK2Ub3Z5bLq2pInZ3HrImaCUTWvPoJUW9e180glBYApywNdd4KbDoNB Dm32slE+qksLfbGM/KLHIzqKKaGsNTU4Kmj8o2fneOX7Y569/ZcDMo+dv8Eb6Bv0 IT2dnHQuhB3uUbcWhJe34xJPBYvFdE05HFjp2gjGbGnCi4eymOYkAnDobvYc194o OcIMRWJpmkG12pAnCu6uD49rmrbIXYNcHYyrfA9o0yfyrJDFj0lizhP7klS4UAN1 zqytCmWIL194CNHHVapNDYpggHlR/W8BFJeQqovyTzQ7sddj6SOF6h/0Iv8h9xwL jrK0IxS0AwAyJlAAxx55+DIpHnWnrAELwdrfxD2LQ4MM2jvi06TheWkdM55iNTI5 G635BMxX4+QeGjcJ1ca0EGLLSYtvYrjmQxJlrctPhYeq9H5rjTZjffVtZSra9FIj F/OKmWhtpCz/amqWV1oMV9izmeFbdbNAr8grqbFUYyPTKpGNzxCUzPDYcRkt21hY ftE3HwMEaER9m1/idEZH =XZce -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6B63C559-C48C-4824-9D24-87FF89336FE4>