search for: mipsisellowering

> > The problem is with libgcc2, which contains libcalls needed to support > some operations > your processor cant directly do. > Yes, I mix up libgcc2 with libcpp... I have advanced a little, commenting out the fp functions. Now, it stucks at unwind-dw2.c. MipsISelLowering.cpp gives the error: Unsupported calling convention. By the way, I understand that these functions are treated by LLVM like built-in functions, and MipsISelLowering purpose is to match the arguments and return types? Any idea of which function can be? Thanks for all. -------------- next part ---...

Hi Julio, On Mon, Jul 7, 2008 at 6:53 AM, Julio <julio.martin.hidalgo at gmail.com> wrote: > And one last thing, the problem seems to be related to libcpp. Using only C > frontend will work? The problem is with libgcc2, which contains libcalls needed to support some operations your processor cant directly do. >> Actually, I don't need fp, there is any way to disable?

...out); p = &c; __asm volatile ( "lwl %0, 1 + %1\n\t" "lwr %0, 2 + %1\n\t" : "=r"(out) : "R"(*p) ); printf("out is %x\n", out); return 0; } LLVM-MIPS-BE diff: diff --git a/lib/Target/Mips/MipsISelLowering.cpp b/lib/Target/Mips/MipsISelLowering.cpp index 36e1a15..4a5d045 100644 --- a/lib/Target/Mips/MipsISelLowering.cpp +++ b/lib/Target/Mips/MipsISelLowering.cpp @@ -3880,6 +3880,8 @@ getConstraintType(const std::string &Constraint) const case 'l': case 'x':...

Hi Andrea    Thank you your replying.    I do like your letter. Add following to line to MipsISelLowering.cpp. As your words,   @llvm.convert.to.fp16  can compile successfully. However, the runtime is not right. +  setOperationAction(ISD::FP16_TO_FP32, MVT::f32, Expand);+  setOperationAction(ISD::FP32_TO_FP16, MVT::i32, Expand); Robin yalong at multicorewareinc.com  From: Andrea Di BiagioDate: 2014-0...

...> cheers, > --renato Not yet, these two failures were the first time we had seen the problem. We're still looking into fixing it properly but I'm currently thinking that the correct fix is to add if (Subtarget.isGP64bit()) setOperationAction(ISD::SETCC, MVT::i32, Promote); to MipsISelLowering.cpp and sort out the consequences of this on the patterns for all the comparison instructions. This is likely to be a fairly big change to our target.

...TruncIntFP > nodes. There'll be some constraint it's not checking or an unexpected > node type, probably related to -msingle-float. I'm afraid I'm not sure > what yet. > I'm reasonably sure the function producing that node is lowerFP_TO_SINT_STORE in lib/Target/Mips/MipsISelLowering.cpp. The node before that function executes has an fp_to_sint node which seems to want to convert an i64 to an f32 which seems...rather odd to me, honestly. The PS2, for what it's worth, only has an i32 -> f32 instruction, so I think there's an impedance mismatch somewhere. ------------...

Has anyone experimented with generating non-PIC for MIPS64 and the n64 ABI? Currently MipsISelLowering.cpp uses conditions like: if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { } around any PIC code generation. Is generating non-PIC just untested, or is it known not to work? I can't find any discussion of it anywhere. I ran into this when trying to see why --reloca...

...y comment lh, lhu, and sh to make llvm not to choose these instruction when compiling, however, it usually cause a 'can not select ...' error when using 'short' data type in source code. Then I tried to expand these instructions in EmitInstrWithCustomInserter in file lib/Target/Mips/MipsISelLowering.cpp, just as commit in: https://github.com/geraint0923/LLVM-ThuMips/commit/6a9ca907f3e945c2bb1f9627e0e5fdcbd7964da2 It works fine for lh and lhu, and fails for sh: when expanding sh, there are four instruction, but in *.s generated by modified llvm's llc, there are only two instructions which...

...eBasicBlock&, llvm::VirtRegMap&, llvm::AvailableSpills&, llvm::BitVector&, std::vector<llvm::MachineOperand*, std::allocator<llvm::MachineOperand*> >&)': llvm/llvm/lib/CodeGen/Spiller.cpp:947: warning: unused variable 'TID' llvm/llvm/lib/Target/Mips/MipsISelLowering.cpp: In member function 'llvm::SDValue llvm::MipsTargetLowering::LowerFORMAL_ARGUMENTS(llvm::SDValue, llvm::SelectionDAG&)': llvm/llvm/lib/Target/Mips/MipsISelLowering.cpp:958: warning: 'Opcode' may be used uninitialized in this function

On Thu, 6 Sep 2018, 16:31 Tim Northover, <t.p.northover at gmail.com> wrote: > > The PS2, for what it's worth, only has an i32 -> f32 instruction, so I > think there's an impedance mismatch somewhere. > > This is also a fairly common situation. If the operation can be > emulated with a reasonably small number of native instructions you can > often get LLVM to

...make llvm not to > choose these instruction when compiling, however, it usually cause a > 'can not select ...' error when using 'short' data type in source code. > Then I tried to expand these instructions in > EmitInstrWithCustomInserter in file > lib/Target/Mips/MipsISelLowering.cpp, just as commit in: > > https://github.com/geraint0923/LLVM-ThuMips/commit/6a9ca907f3e945c2bb1f9627e0e5fdcbd7964da2 > > It works fine for lh and lhu, and fails for sh: > when expanding sh, there are four instruction, but in *.s generated by > modified llvm's llc, there ar...

Hello, I'm part of the (sadly fairly small) community of PS2 hackers. The current cross-toolchain for the PS2 is based on GCC 3.2.3, an outdated and buggy compiler, which I have personally gotten tired of working with, so I would like to port Clang as a newer cross-compiler for the PS2. However, the PS2 has some notable quirks which make this a non-trivial task for the current compiler. It

...nd sh to make llvm not to > choose these instruction when compiling, however, it usually cause a 'can > not select ...' error when using 'short' data type in source code. > Then I tried to expand these instructions in EmitInstrWithCustomInserter > in file lib/Target/Mips/MipsISelLowering.cpp, just as commit in: > > > https://github.com/geraint0923/LLVM-ThuMips/commit/6a9ca907f3e945c2bb1f9627e0e5fdcbd7964da2 > > It works fine for lh and lhu, and fails for sh: > when expanding sh, there are four instruction, but in *.s generated by > modified llvm's llc, ther...

...ailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Brandon Hill > *Sent:* 29 April 2014 22:35 > *To:* llvmdev at cs.uiuc.edu > *Subject:* [LLVMdev] MIPS n64 ABI and non-PIC > > > > Has anyone experimented with generating non-PIC for MIPS64 and the n64 > ABI? Currently MipsISelLowering.cpp uses conditions like: > > if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { > > } > > > > around any PIC code generation. Is generating non-PIC just untested, or > is it known not to work? I can't find any discussion of it anywhere. I ra...

On 07/09/2014 12:41 PM, Matt Arsenault wrote: > On 07/09/2014 03:30 PM, yalong at multicorewareinc.com wrote: >> Thank you Kevin!!! >> If I use fptrunc and bitcast realise NEON vcvtt ( I can sure, >> "fptrunc double %tmp to float" is right, but "fptrunc float %tmp to >> half" is wrong). My target platform is MIPS. The command as following:

...ction when compiling, however, it usually >> cause a 'can not select ...' error when using 'short' data type >> in source code. >> Then I tried to expand these instructions in >> EmitInstrWithCustomInserter in file >> lib/Target/Mips/MipsISelLowering.cpp, just as commit in: >> >> https://github.com/geraint0923/LLVM-ThuMips/commit/6a9ca907f3e945c2bb1f9627e0e5fdcbd7964da2 >> >> It works fine for lh and lhu, and fails for sh: >> when expanding sh, there are four instruction, but in *.s >> generat...

...hese two failures were the first time we had seen the problem. > We're still looking into fixing it properly but I'm currently thinking that the > correct fix is to add > > if (Subtarget.isGP64bit()) > > setOperationAction(ISD::SETCC, MVT::i32, Promote); > > to MipsISelLowering.cpp and sort out the consequences of this on the > patterns for all the comparison instructions. This is likely to be a fairly big > change to our target. > > Right, so the best thing is probably reverting this one for 3.6.1. > > cheers, > --renato I agree. I reverted it thi...

Hi, if I want to know how switch instructions are handled in the backend, where do I have to look first? I'm not familiar with the backend framework and I couldn't figure out the interface between the LLVM instruction 'SwitchInst' and whatever there is in the backend. I would be very happy about every hint where I have to look to find the entry point of switch instructions in the

...ant to predicate the changes I > made on Subtarget->isSingleFloat() I think (probably in combination > with the actual types, since f32 -> i32 ought to still be OK with the > existing code). The main annoyance there is that lowerFP_TO_SINT_STORE > is static rather than a member of MipsISelLowering so it doesn't have > access to Subtarget. Personally, I'd just make it a member function to > fix that. > lowerFP_TO_SINT_STORE is only ever called by lowerFP_TO_SINT, so I'm just passing single-floatness (we need a better name for that) as an argument to lowerFP_TO_SINT_STORE...

Hi all, -soft-float can not be rightly use by llc. All float function operation will call soft float, but not hard. My mips device cannot support half float type, so I hack the llvm, and add soft half float and add -soft-float option. I add the function define for __gnu_f2h_ieee() and __gnu_h2f_ieee (), and it can call the soft half float. However, all the others function about