On 10/29/14 17:18, Tim Lewis wrote:
> Scott --
>
> For historical perspective, the EDK2 build flags have focused on
> space over speed because of the code size constraints placed on
> flash-resident code. Not being as familiar with gcc as I am with
> VS20xx, I don't know whether these can be set together.
Maybe I'm misunderstanding (and in that case I apologize), but I'm under
the impression that you are misunderstanding '-Os'. '-Os' optimizes for
size, not speed. So Scott's patch seems to be aligned with the
tradition. (Currently no gcc optimizations are enabled at all when
building for X64, neither for speed nor for size.)
-Os Optimize for size. -Os enables all -O2 optimizations that
do not typically increase code size. It also performs
further optimizations designed to reduce code size.
-Os disables the following optimization flags:
-falign-functions -falign-jumps -falign-loops
-falign-labels -freorder-blocks
-freorder-blocks-and-partition -fprefetch-loop-arrays
-ftree-vect-loop-version
Again I'm sorry if I misunderstood you.
Thanks
Laszlo
>
> Tim
>
> -----Original Message-----
> From: Scott Duplichan [mailto:sc...@notabs.org]
> Sent: Tuesday, October 28, 2014 9:59 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] Enable optimization for gcc x64 builds
>
> Optimization is not enabled for x64 builds using gcc 4.4-4.9. For
> IA32 builds, -Os (optimize for small code size) is used. Why is this?
> Apparently it is because variable argument list handling fails when
> gcc X64 optimization is enabled. The solution is an improvement to
> the patch of SVN rev 10440:
> http://sourceforge.net/p/edk2/mailman/message/25121111/
>
> The patch in this email only adds gcc X64 optimization for gcc
> versions 4.8 and newer. This is because testing with older versions
> of gcc is a lot of work. On the other hand, the patch could be a lot
> simpler if it were to ignore gcc version. The patch is boot tested
> using Duet with gcc 4.8.2 and gcc 4.9.1. For these two cases, the
> print formatting problem is resolved by the patch.
>
> Should we:
> 1) Restrict the change to recent gcc versions where testing is easy
> (approach of included patch)
> 2) Apply the change to all gcc versions, and let older versions go
> untested?
> 3) Try to find/build the needed older gcc versions so that the patch
> can apply to all versions and be tested too
>
> Thanks,
> Scott
>
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
