archaic/useless CFLAGS options for x86 boot blocks
This email is in part inspired by the following problem: http://article.gmane.org/gmane.os.freebsd.current/135292 So harmful could also be added to the subject line. So here is my proposal. Part I. ZFS and GPT bootblocks. I believe that we do not need here any extra optimizations and happy dances that seem to be carried over from boot2. I think that just the -Os should be sufficient of optimization flags. Maybe even that is not really required. Rationale: - these boot blocks are not as nearly space-constrained as boot2 - using untypical flags increases chances of hitting compiler bugs, especially for those compilers where we are stuck with unsupported / locally-maintained versions or where a compiler is maturing yet - assembly / machine code and debugging may become easier Additionally, the '/align/d' '/nop/d' filtering of the intermediate assembly file seems to be not needed for zfsboot. Part II. The original boot2. My testing shows that -Os -fomit-frame-pointer are sufficient to produce a small enough boot2 image (~300 bytes remain available with gcc, 51 bytes for clang). -mrtd -mregparm=3 do not change size with gcc, but with clang they increase _available_ space to 79 bytes. The '/align/d' '/nop/d' filtering seems to shave off only 7 bytes here. Not suggesting anything, just an observation... Part III. History. It seems that all those optimization related options were introduced very long time ago when the compiler(s) were quite different from what they are now. So, some re-evaluation may be (long over)due. For example, -fno-unit-at-a-time is definitely an anti-optmization option and it was introduced to fight some gcc bugs way back in 2004 (r132870). Its merits have never been re-evaluated after switch to gcc 4.2, it seems. -fno-guess-branch-probability and -mno-align-long-strings are even less obvious options (see e.g. r108149). Finally, here is a diff: http://people.freebsd.org/~avg/boot-cflags.diff All the boot blocks are boot tested in qemu. boot2 is also tested with -mrtd -mregparm removed. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: archaic/useless CFLAGS options for x86 boot blocks
on 12/09/2011 10:36 Andriy Gapon said the following: This email is in part inspired by the following problem: http://article.gmane.org/gmane.os.freebsd.current/135292 So harmful could also be added to the subject line. So here is my proposal. I would like to clarify that my intention was to solicit opinions, explanations, discussions, alternative proposals and *testing*. Part I. ZFS and GPT bootblocks. I believe that we do not need here any extra optimizations and happy dances that seem to be carried over from boot2. I think that just the -Os should be sufficient of optimization flags. Maybe even that is not really required. Rationale: - these boot blocks are not as nearly space-constrained as boot2 - using untypical flags increases chances of hitting compiler bugs, especially for those compilers where we are stuck with unsupported / locally-maintained versions or where a compiler is maturing yet - assembly / machine code and debugging may become easier Additionally, the '/align/d' '/nop/d' filtering of the intermediate assembly file seems to be not needed for zfsboot. Part II. The original boot2. My testing shows that -Os -fomit-frame-pointer are sufficient to produce a small enough boot2 image (~300 bytes remain available with gcc, 51 bytes for clang). -mrtd -mregparm=3 do not change size with gcc, but with clang they increase _available_ space to 79 bytes. The '/align/d' '/nop/d' filtering seems to shave off only 7 bytes here. Not suggesting anything, just an observation... Part III. History. It seems that all those optimization related options were introduced very long time ago when the compiler(s) were quite different from what they are now. So, some re-evaluation may be (long over)due. For example, -fno-unit-at-a-time is definitely an anti-optmization option and it was introduced to fight some gcc bugs way back in 2004 (r132870). Its merits have never been re-evaluated after switch to gcc 4.2, it seems. -fno-guess-branch-probability and -mno-align-long-strings are even less obvious options (see e.g. r108149). Finally, here is a diff: http://people.freebsd.org/~avg/boot-cflags.diff All the boot blocks are boot tested in qemu. boot2 is also tested with -mrtd -mregparm removed. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: archaic/useless CFLAGS options for x86 boot blocks
On Monday, September 12, 2011 3:36:54 am Andriy Gapon wrote: This email is in part inspired by the following problem: http://article.gmane.org/gmane.os.freebsd.current/135292 So harmful could also be added to the subject line. So here is my proposal. Part I. ZFS and GPT bootblocks. I believe that we do not need here any extra optimizations and happy dances that seem to be carried over from boot2. I think that just the -Os should be sufficient of optimization flags. Maybe even that is not really required. Rationale: - these boot blocks are not as nearly space-constrained as boot2 - using untypical flags increases chances of hitting compiler bugs, especially for those compilers where we are stuck with unsupported / locally-maintained versions or where a compiler is maturing yet - assembly / machine code and debugging may become easier Additionally, the '/align/d' '/nop/d' filtering of the intermediate assembly file seems to be not needed for zfsboot. Part II. The original boot2. My testing shows that -Os -fomit-frame-pointer are sufficient to produce a small enough boot2 image (~300 bytes remain available with gcc, 51 bytes for clang). -mrtd -mregparm=3 do not change size with gcc, but with clang they increase _available_ space to 79 bytes. The '/align/d' '/nop/d' filtering seems to shave off only 7 bytes here. Not suggesting anything, just an observation... Part III. History. It seems that all those optimization related options were introduced very long time ago when the compiler(s) were quite different from what they are now. So, some re-evaluation may be (long over)due. For example, -fno-unit-at-a-time is definitely an anti-optmization option and it was introduced to fight some gcc bugs way back in 2004 (r132870). Its merits have never been re-evaluated after switch to gcc 4.2, it seems. -fno-guess-branch-probability and -mno-align-long-strings are even less obvious options (see e.g. r108149). Finally, here is a diff: http://people.freebsd.org/~avg/boot-cflags.diff All the boot blocks are boot tested in qemu. boot2 is also tested with -mrtd -mregparm removed. I suspect some of the recent changes to shave space down for Clang have made some of the optimization options no longer necessary. I think the patch is fine, and I'd even prefer to go ahead and drop the extra cruft (like removing nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: archaic/useless CFLAGS options for x86 boot blocks
on 12/09/2011 14:43 John Baldwin said the following: I suspect some of the recent changes to shave space down for Clang have made some of the optimization options no longer necessary. Just a note of all the options in question were added long before clang. I think the patch is fine, and I'd even prefer to go ahead and drop the extra cruft (like removing nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well. I personally agree, thank you for this suggestion. My current plan is to leave boot2 alone until stable/9 is branched, but to try to get zfs/gpt boot changes into 9.0. What do you think? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: archaic/useless CFLAGS options for x86 boot blocks
On Monday, September 12, 2011 8:02:30 am Andriy Gapon wrote: I think the patch is fine, and I'd even prefer to go ahead and drop the extra cruft (like removing nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well. I personally agree, thank you for this suggestion. My current plan is to leave boot2 alone until stable/9 is branched, but to try to get zfs/gpt boot changes into 9.0. What do you think? I think this is fine. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: archaic/useless CFLAGS options for x86 boot blocks
on 12/09/2011 15:26 John Baldwin said the following: On Monday, September 12, 2011 8:02:30 am Andriy Gapon wrote: I think the patch is fine, and I'd even prefer to go ahead and drop the extra cruft (like removing nops and aligns as well as -mrtd and -mregparm) from the UFS boot2 as well. I personally agree, thank you for this suggestion. My current plan is to leave boot2 alone until stable/9 is branched, but to try to get zfs/gpt boot changes into 9.0. What do you think? I think this is fine. Another thing that was suggested to me via private communication is to change -Os to -O1 for those non-constrained boot blocks. I do not see anything wrong with that. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
