optimization passes through c++

Hey all,

I am trying to run llvm's optimzation passes (basically as many as possible :p), but apparently there is no effect (dumped .ll-file before and after optimization -> identical).
I am wondering if the method is just not optimizable in *any* way or if I am not invoking the stuff correctly.
The system setup on a broad scale looks as follows:
- custom LLVM-module pass
- at some point inside the runOnModule(), it instantiates a PassManager, adds all kinds of optimizations ( PM.add(createXYZPass()) ) and runs them on a provided module.
- the module is provided by a bitcode file that is generated with llvm-g++ from a c++-file.

There are several problems with the bitcode generated by llvm-g++:
- I understand that in LLVM 2.5 all optimizations of gcc are disabled. this leads to horrible code with a lot of unnecessary alloc/gep/load/store stuff
- however, there seems to be one optimization that is particularly nasty and I do not know how to disable it: at certain points where a struct with three floats is supplied, the struct is split into a double and a float (for loading/storing, but this also affects function signatures!)

the functions I am running this on look like the following:
struct Point {
    float x;
    float y;
    float z;
}
extern "C" void test
    (
        int a,
        float f,
        Point p0,
        Point p1,
        float x,
        Point & result
    );

only the result should be stored back (and is usually only used once at the end of the function), all other values should not invoke any allocations or loads/stores...

I hope someone can help me out here.

Regards,
Ralf

Ralf Karrenberg wrote:

- however, there seems to be one optimization that is particularly nasty and I do not know how to disable it: at certain points where a struct with three floats is supplied, the struct is split into a double and a float (for loading/storing, but this also affects function signatures!)

I don't think this is an optimization. It does this (at least, for functions signatures) to be compatible with regular (non-llvm) gcc/g++.
For example, this would generate the appropriate code if your llvm-g++ is targeted at x86-64. (So would using { <2 x float>, float } instead, probably, but that's another matter...)