[eigen] Eigen code gets optimized away by avr-g++ - what to do?

[Ryan Pavlik <rpavlik@xxxxxxxxxxx>]

All,

Hoping for a little help with an interesting issue. As I need to do some small matrix/vector math on the Arduino, and in the interest of using a well-tested, efficient library I'm already using elsewhere, I've "ported" Eigen to the Arduino/AVR.  I've uploaded my example repo/testcase here: https://github.com/rpavlik/eigen-avr-testcase

Really, there was not much to the port - one warning fix here https://github.com/rpavlik/eigen-avr-testcase/commit/864bb30ecac75044264b0c7b4c250a36268851a8 because ptrdiff_t is 16-bits, improvements to the AVR/Arduino uClibc++ port here https://github.com/rpavlik/StandardCplusplus, and one "dummy" header file to cope with the Arduino IDE's way of implicitly indicating you want to use a library, as well as to work around a few small compile issues https://github.com/rpavlik/eigen-avr-testcase/blob/master/libraries/Eigen30/Eigen30.h .

However, I am now seeing quite strange behavior. It looks like Eigen code (and possibly the rest of the function in which it is used?) gets optimized out of the compiled binary.  (It's so efficient, it doesn't have any code! :D )  When built by the IDE, it uses -Os optimization (which is -O2 without the ones deemed to potentially enlarge the code) which triggers the issue. -O1 optimization doesn't seem to trigger it (by looking at the disassembly, I actually see a call to sqrtf when my test program calls .norm() on a vector) though I haven't actually run that code on a device.

In the testcase repo I posted above, there are instructions on how to build this on the command line with varying optimization values and automatically do the disassembly. I've also attached the disassembled contents from my machine: building with avr-gcc as included in Ubuntu 10.04 x64 (4.3.4) - similar results occur with the compiler bundled with Arduino Linux x64 and Arduino for Windows, as well as with avr-gcc 4.7.0 on Windows.  The O2 and Os files are basically identical, but you can see the change from O1 to Os beyond just memory locations: a big chunk near the top is removed.

So, what I'm hoping someone might be able to do is take a look at this and offer suggestions of why this might be occurring (assumptions in Eigen? bug in the AVR backend for GCC?). I'd also appreciate some guidance if the "warning fix" I mentioned above makes any sense, or if there's something else I should do to properly resolve that issue, and also whether the workarounds/fixes in the dummy header should be moved into the main Eigen tree or otherwise resolved at that level.

(FWIW, I also tried 3.1 with similar results)

Thanks for any help you might be able to offer!

Ryan

--
Ryan Pavlik
HCI Graduate Student
Virtual Reality Applications Center
Iowa State University

rpavlik@xxxxxxxxxxx
http://academic.cleardefinition.com

Attachment: build_with_O1.S
Description: Binary data

Attachment: build_with_O2.S
Description: Binary data

Attachment: build_with_Os.S
Description: Binary data