History log of /external/llvm/lib/Target/Mips/MipsOs16.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
b109ea8245e2948ea6d06a6e6cbab7c6788da211 22-Apr-2013 Akira Hatanaka <ahatanaka@mips.com> 80 columns.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180040 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/Mips/MipsOs16.cpp
74adad6de8cf947257a53bb08364fa0f4f71b10e 10-Apr-2013 Reed Kotler <rkotler@mips.com> This is for an experimental option -mips-os16. The idea is to compile all
Mips32 code as Mips16 unless it can't be compiled as Mips 16. For now this
would happen as long as floating point instructions are not needed.
Probably it would also make sense to compile as mips32 if atomic operations
are needed too. There may be other cases too.

A module pass prescans the IR and adds the mips16 or nomips16 attribute
to functions depending on the functions needs.

Mips 16 mode can result in a 40% code compression by utililizing 16 bit
encoding of many instructions.

The hope is for this to replace the traditional gcc way of dealing with
Mips16 code using floating point which involves essentially using soft float
but with a library implemented using mips32 floating point. This gcc
method also requires creating stubs so that Mips32 code can interact with
these Mips 16 functions that have floating point needs. My conjecture is
that in reality this traditional gcc method would never win over this
new method.

I will be implementing the traditional gcc method also. Some of it is already
done but I needed to do the stubs to finish the work and those required
this mips16/32 mixed mode capability.

I have more ideas for to make this new method much better and I think the old
method will just live in llvm for anyone that needs the backward compatibility
but I don't for what reason that would be needed.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179185 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/Target/Mips/MipsOs16.cpp