static functions and optimization

I have some stub functions that are essentially static, but they cannot be removed.

What linkage type should I use in that case. Internal linkage appears to get the functions discarded if they are not referenced under certain optimizations.

This is part of the gcc mips16 hack for floating point.

For example, a function like floor from the math library will be called with an external reference to function floor.

At that time, the compiler does not know whether floor was compiled as mips16 or mips32.

It generates the call to floor as if it is a mips16 compiled function.

It also generates a stub that the linker can use if during link time it is discovered that "floor" is a mips32 function.

The stubs, which are mips32 code, will move the first argument register into a floating point register, call floor, and upon return will move the integer return value into a floating point register.

If I designate this function as having internal linkage, then in some cases, the optimizer will throw it away.

In that case, at link time it will call floor, and if floor is compiled as mips32, this will break a mips16 compiled program.

The linker does not know there is an issue because only functions with certain kinds of signatures need a helper function for the call.

Maybe there is some attribute I can add this will not allow the function to be discarded.

Seems like -femit-all-decls partially works around this.

But I would still like to solve the real problem of creating a function which is local/static but which cannot be thrown away by the optimizer if not referenced.

I have some stub functions that are essentially static, but they cannot
be removed.

What linkage type should I use in that case. Internal linkage appears to
get the functions discarded if they are not referenced under certain
optimizations.

This is part of the gcc mips16 hack for floating point.

For example, a function like floor from the math library will be called
with an external reference to function floor.

At that time, the compiler does not know whether floor was compiled as
mips16 or mips32.

This description below is not completely correct. But the issue remains nevertheless that some of the static function stubs are being optimized below.

I have filed a bug against myself to finally document this mips16/32 floating point interoperability scheme. Even after implementing it, I forget parts of how it works if I have not worked on it for a while.

llvm.used should do it.