similar to: [LLVMdev] use-soft-float attribute

On 01/04/2013 07:45 PM, Eli Friedman wrote: > On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: >> On 01/04/2013 06:08 PM, Eli Friedman wrote: >>> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: >>>> I'm working on mips16 hard float which at a first approximation is just >>>> soft

On 01/04/2013 06:08 PM, Eli Friedman wrote: > On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: >> I'm working on mips16 hard float which at a first approximation is just soft >> float but calls different library routines. Those different library routines >> are just an implementation (in mips32 mode) of soft float using mips32 >>

On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: > On 01/04/2013 06:08 PM, Eli Friedman wrote: >> >> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> I'm working on mips16 hard float which at a first approximation is just >>> soft >>> float but calls different library

On 01/08/2013 01:48 PM, Eli Friedman wrote: > On Mon, Jan 7, 2013 at 6:07 PM, reed kotler <rkotler at mips.com> wrote: >> For example: >> >> /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel >> -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float > Try something like the following: > > float f; > double test(void*

On Mon, Jan 7, 2013 at 4:16 PM, reed kotler <rkotler at mips.com> wrote: > On 01/04/2013 07:45 PM, Eli Friedman wrote: >> >> On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> On 01/04/2013 06:08 PM, Eli Friedman wrote: >>>> >>>> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com>

For example: /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float On 01/04/2013 07:45 PM, Eli Friedman wrote: > On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: >> On 01/04/2013 06:08 PM, Eli Friedman wrote: >>> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler

On Tue, Jan 8, 2013 at 6:33 PM, reed kotler <rkotler at mips.com> wrote: > On 01/08/2013 01:48 PM, Eli Friedman wrote: >> >> On Mon, Jan 7, 2013 at 6:07 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> For example: >>> >>> /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel >>> -relocation-model=pic -o

I'm implementing this unusual gcc form of mips16 hard float. I ran into one unexpected wrinkle. It effects efficiency as opposed to correctness but I'd like to figure out the best way to resolve it. The signatures for the libcall routines have floating point arguments in at least some situations. I have not fully examined if it's all of them. So in callinfo while I'm lowering

I'm working on mips16 hard float which at a first approximation is just soft float but calls different library routines. Those different library routines are just an implementation (in mips32 mode) of soft float using mips32 hardware instructions. This part is already done. (mips16 mode has no floating point instructions). The next level of this that I am working on now is the ability to

What happens here is that the code that is doing the "softening", generates a libcall On closer inspection, llvm is doing half of this correctly. The signature for the soft float function for extending a float to double is of the form: i64 xxx_extendsfdf2(float); But it should be i64 xxx_extendsfdf2(i32) This particular paradigm is duplicated many times in the the float type

On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: > I'm working on mips16 hard float which at a first approximation is just soft > float but calls different library routines. Those different library routines > are just an implementation (in mips32 mode) of soft float using mips32 > hardware instructions. This part is already done. (mips16 mode has no

On Mon, Jan 7, 2013 at 6:07 PM, reed kotler <rkotler at mips.com> wrote: > > For example: > > /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel > -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float Try something like the following: float f; double test(void* fptr) { f = ((float(*)(float,float))fptr)(1.0, 1.0); } -Eli

Yes, you could have mips16 and fastcc. Mips16 just means that processor mode to execute that function is "mips16". So in a mips16 designated function, I will just emit mips16 instructions and in a "nomips16" function, just emit normal mips32 instructions. I tend to call this "mips32" normal mode, "standard encoding" because in reality the processor is

We are starting to look at the mips16 and micro mips ports. There are various design issues that people may have some good input on. Especially in how to structure the TD files and other optimizer issues. Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I understand. Mips16 or Micro Mips can live inside of either MIPS32 or MIPS64. In gcc, it's possible using attributes to

I can't say this is a bug it is changed behavior from before the new attribute scheme. This issue may appear with other attributes. (there are other attributes that clang will now place on each function) If you run clang as a single pass to create a .ll and don't say -msoft-float, it puts the attribute use-soft-float=false on every function. (It used to be that in that case

I need to be able to emit .globl for the soft float routines used by mips16. The routines are called but there is no .globl definition for them. How can I do this? Background: I have a strange issue that I encountered with mips16 hard float. Part of mips16 hard float is to emit calls to runtime routines with the same signature as usual soft float routines, except that they are implemented

I think that Bill Wendlings new attribute implementation would allow me to do this but it is not ready yet. Maybe it's okay to just add them to the list of function attributes as I suggested. But in the end, someone has to approve the checkin. On 01/11/2013 07:35 AM, Reed Kotler wrote: > Yes, you could have mips16 and fastcc. > > Mips16 just means that processor mode to execute

On 05/14/2012 02:42 PM, Jakob Stoklund Olesen wrote: > On May 14, 2012, at 2:28 PM, reed kotler wrote: > >> I'm not using getMinimalPhysRegClass. Some target independent code is using it. > Probably PEI. > >> It makes trouble for us and I would like to submit a patch to make it a virtual function so that I can override it and make it meaningful for Mips, as long as this

Reed, On May 14, 2012, at 3:45 PM, reed kotler <rkotler at mips.com> wrote: > On 05/14/2012 02:42 PM, Jakob Stoklund Olesen wrote: >> On May 14, 2012, at 2:28 PM, reed kotler wrote: >> >>> I'm not using getMinimalPhysRegClass. Some target independent code is using it. >> Probably PEI. >> >>> It makes trouble for us and I would like to

I have pushed almost all the changes for the mips16 port and it passes about 90% of the single source tests from test-suite. It is still an experimental port but I am working hard to finish up the last details as soon as possible. Some things that are incomplete: 1) It is using soft float at this time. I did not like the gcc mips16 floating point design and will do something much better for