-O2/-O3 Optimization bug?

Mike none at none.com
Wed Jan 22 16:09:33 PST 2014


On Wednesday, 22 January 2014 at 13:08:53 UTC, Iain Buclaw wrote:
> Personally, I would never use -O3 for low level start.o kernel 
> stuff.

In my simple D program, however, -O2 also doesn't work.

> As you are coding on a small board, wouldn't you instead use 
> -Os ?

I sometimes use -Os and sometimes use -O2/-O3.

If I'm controlling something low-speed like a refrigerator or 
other kitchen appliance, I use -Os so I can use the cheapest chip 
available.

However, for my current project, I'm making and HMI/Industrial 
controller.  The HMI will have a software rendered graphics 
engine with vector graphics, alpha blending, TrueType fonts, 
etc... I've already built this in C++, and the -O2/-O3 was very 
significant in my performance benchmarks.  I didn't notice any 
difference between -O2 and -O3, though.  It uses about 700KB of 
Flash memory, and most of that is the TrueType font data, so I'm 
quite satisfied with my C++ results.

Interestingly, since I started using GCC 4.8 in my C++ project, 
-O3 breaks my memset function, but -O2 does not, so I'm sticking 
with -O2 at the moment.  With GCC 4.7, -O3 worked fine.

If you can't see any error in my D code and the compiler and 
optimizer are working properly, shouldn't my program work at 
these optimization levels without resorting to special qualifiers 
like shared/volatile?

NOTE: I'll post assembly and the optimization tree when I get 
home from work today.


More information about the D.gnu mailing list