Open jsonn opened 12 years ago
Good enough. Working around the related PR 12348 side steps the issue completely for me, so keeping the example for analysis is good enough.
There is a lot of luck involved in getting the "right" codegen for a particular loop nest. Performance results are just as jittery as the size results shown here. The good news is:
the new default looks like a significant improvement in overall size
with the new default (-enable-iv-rewrite=false) someone writing their own boot loader could conceivably hand tune loops without llvm undoing the work. If llvm still gets in the way, try -mllvm -disable-lsr (as an unsupported workaround).
I can leave this open because there is an opportunity to make the LSR pass aware of the -Oz option, and this is potentially a good example to motivate it. That said, it's very low on my list of enhancements to add.
Hm. I thought qsort.i had a large regression, but I might have messed up the list at that point. subr_prf.i is what triggered the investigation: it ended up with 120 Bytes overhead.
I'm having trouble knowing what to look at here. When I run compile.sh and simply sum the .o sizes, I get a larger size for enable-iv-rewrite=true. I'm using svn r153254.
false: 54760 bytes true: 55508 bytes
Extended Description
Attached is the list of all files from NetBSD's libkern, libsa and libi386 that differ in code size between -enable-iv-rewrite=false and -enable-iv-rewrite=true. Some of them are not used in this context. The false.txt / true.txt list the object sizes as I see it during the release build. compile.sh /.i will compile the files with both options. Big regressions are e.g. qsort.i, improvements are seen for subr_prf.i