User: Password:
|
|
Subscribe / Log in / New account

Rethinking optimization for size

Rethinking optimization for size

Posted Feb 11, 2013 18:45 UTC (Mon) by Aliasundercover (subscriber, #69009)
In reply to: Rethinking optimization for size by daglwn
Parent article: Rethinking optimization for size

In times past I often reviewed the code output from compilers I was working with. It was helpful to calibrate what idioms carried what costs and track how they changed with compilers.

I still get the itch to look now and then but mostly recoil in horror at how hard it is to relate the code GCC gives me to what I wrote. Typically I have some function I want to review but give up after 10 minutes of searching the listing without finding it. The listing is of course fabulously ugly but that is no change from any other compiler I ever used. I just don't find my code. Well, I do, but it is all in a huge block of raw C code without the corresponding output.

No doubt some cool optimization hoisted my code out of its place in the C code I wrote and dropped it some place which makes sense to the compiler. No doubt all this transformation is good for run time performance or size or something. Perhaps listing quality just isn't an interesting bit of work for compiler writers.

I used to know what those old Windows and SunOS compilers would do with my code but now I have no similar feeling for GCC. I can read what people write about indexing vs. pointers and signed vs. unsigned but I used to really know from first hand observation.

I wish the listing got more respect. It can be a powerful optimization tool.

Maybe I just do it wrong. My makefile has the following incantation for generating listings.

%.lst: %.c
$(CC) $(CFLAGS) $(CPPFLAGS) -g -Wa,-a,-ad -c $< > $@


(Log in to post comments)

Rethinking optimization for size

Posted Feb 11, 2013 19:25 UTC (Mon) by daglwn (guest, #65432) [Link]

> The listing is of course fabulously ugly but that is no change from any
> other compiler I ever used.

This is actually a quality of implementation issue. There are compilers out there that give fantastic listings, even down to a mostly-readable highish-level decompliation even after very aggressive code transformations. This is not very easy to obtain and really has to be baked-in at the beginning of the compiler design.

But you're right in that a good compiler will make your code unrecognizable. :)

> I wish the listing got more respect. It can be a powerful optimization
> tool.

Indeed. I don't think there's much one can do with gcc to get a decent listing. It just doesn't carry enough information. Neither does LLVM, unfortunately, at least AFAIK.

Rethinking optimization for size

Posted Feb 11, 2013 21:09 UTC (Mon) by PaXTeam (guest, #24616) [Link]

maybe you want gcc -S -fverbose-asm for commented assembly output? also -fdump-tree-all and -fdump-rtl-all if you want to see what happens to your C and also relate the internal GIMPLE variable names to the comments in the verbose asm output.

Rethinking optimization for size

Posted Feb 12, 2013 16:28 UTC (Tue) by Aliasundercover (subscriber, #69009) [Link]

Well, you got me there. I tried those dump options and got 151 spam files in my source directory.

-fverbose-asm seems useful. It doesn't help with finding where my code went but the comments are nice.

I wish compiler listings got more respect.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds