search for: mipstargetlow

...EISelLowering.cpp index 4f21921..df6af09 100644 --- a/lib/Target/Mips/MipsSEISelLowering.cpp +++ b/lib/Target/Mips/MipsSEISelLowering.cpp @@ -27,6 +27,9 @@ EnableMipsTailCalls("enable-mips-tail-calls", cl::Hidden, MipsSETargetLowering::MipsSETargetLowering(MipsTargetMachine &TM) : MipsTargetLowering(TM) { // Set up the register classes + + clearRegisterClasses(); + addRegisterClass(MVT::i32, &Mips::CPURegsRegClass); if (HasMips64) diff --git a/lib/Target/Mips/MipsSubtarget.cpp b/lib/Target/Mips/MipsSubtarget.cpp index e11e5d1..4f56bd5 100644 --- a/lib/Target/Mips/MipsSubta...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

The thing I wanted for mips 16 for large literals does not seem to exist right now. They have MipsTargetLowering::isFPImmLegal(const APFloat &Imm, EVT VT) but not the same thing for integer literals. For Mips16, to materialize a 32 bit literal using instructions is expensive, both in terms of the number of registers and the number of instructions. You always want to just do a load of the constan...

...t; an argument in an FP register, you just need to generate a call to the >> relevant helper rather than the function itself. >> >> -Eli > > So just read the DAG in the beginning of MIPS-specific call lowering before > it gets modified? Take a look at CCValAssign etc. in MipsTargetLowering::LowerCall. (The DAG node for the callee doesn't have the necessary information in the general case, even though it might appear to work in simple cases.) -Eli

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 >>

...n FP register, you just need to generate a call to the >>> relevant helper rather than the function itself. >>> >>> -Eli >> So just read the DAG in the beginning of MIPS-specific call lowering before >> it gets modified? > Take a look at CCValAssign etc. in MipsTargetLowering::LowerCall. > (The DAG node for the callee doesn't have the necessary information in > the general case, even though it might appear to work in simple > cases.) > > -Eli I'm not sure if I understood you. For Mips hard float, we also have the soft float option in llc. R...

...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

...t/Mips/Mips16ISelLowering.cpp b/lib/Target/Mips/Mips16ISelLowering.cpp index 6de62cf..23eb537 100644 --- a/lib/Target/Mips/Mips16ISelLowering.cpp +++ b/lib/Target/Mips/Mips16ISelLowering.cpp @@ -39,6 +39,14 @@ namespace { Mips16TargetLowering::Mips16TargetLowering(MipsTargetMachine &TM) : MipsTargetLowering(TM) { + // + // set up as if mips32 and then revert so we can test the mechanism + // for switching + addRegisterClass(MVT::i32, &Mips::CPURegsRegClass); + addRegisterClass(MVT::f32, &Mips::FGR32RegClass); + computeRegisterProperties(); + clearRegisterClasses(); + // Set up t...

...>>> relevant helper rather than the function itself. >>>> >>>> -Eli >>> >>> So just read the DAG in the beginning of MIPS-specific call lowering >>> before >>> it gets modified? >> >> Take a look at CCValAssign etc. in MipsTargetLowering::LowerCall. >> (The DAG node for the callee doesn't have the necessary information in >> the general case, even though it might appear to work in simple >> cases.) >> >> -Eli > > I'm not sure if I understood you. > > For Mips hard float, we als...

...80,6 +3880,8 @@ getConstraintType(const std::string &Constraint) const case 'l': case 'x': return C_RegisterClass; + case 'R': + return C_Memory; } } return TargetLowering::getConstraintType(Constraint); @@ -3928,6 +3930,9 @@ MipsTargetLowering::getSingleConstraintMatchWeight( if (isa<ConstantInt>(CallOperandVal)) weight = CW_Constant; break; + case 'R': // An address that can be used in a non-macro load or store + weight = CW_Memory; + break; } return weight; } Clang-diff: diff --git a/l...

...n FP register, you just need to generate a call to the >>> relevant helper rather than the function itself. >>> >>> -Eli >> So just read the DAG in the beginning of MIPS-specific call lowering before >> it gets modified? > Take a look at CCValAssign etc. in MipsTargetLowering::LowerCall. > (The DAG node for the callee doesn't have the necessary information in > the general case, even though it might appear to work in simple > cases.) > > -Eli -------------- next part -------------- A non-text attachment was scrubbed... Name: hf16_2.c Type: text/...

As many of you will know, handling of struct arguments in LLVM is actually slightly more fiddly than you might expect. For targets where aggregates are always passed on the stack it's easy enough, the Clang ABI code marks these arguments as byval and the call lowering code in LLVM will copy the object to the stack when needed. There are more options for when the target has more complex ABI

...ing code in ARMISelLowering still has logic to split a byval aggregate between the stack and registers (why not I have to say looking at AArch64ISelLowering and the clang code it's not immediately obvious to me where aggregates get split between the stack and registers (which is quite clear in MipsTargetLowering::passByValArg). What am I missing here? It seems to me there are a few possibilities for targets where the ABI indicates aggregates may be passed in registers: * Clang always passes aggregates as byval, LLVM call lowering may assign some or all of the aggregate to registers. Seemingly nobody...

...same road but hasn't implemented O32/N32 yet. * MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. * Many places where hasMips64*() or isGP64bit() are used in the backend. * MSA intrinsic lowering * Legalization configuration * Instruction selection * MipsTargetLowering::getOptimalMemOpType() * And many more. I can provide more detail if you want. Other notables: * RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want....

...same road but hasn't implemented O32/N32 yet. * MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. * Many places where hasMips64*() or isGP64bit() are used in the backend. * MSA intrinsic lowering * Legalization configuration * Instruction selection * MipsTargetLowering::getOptimalMemOpType() * And many more. I can provide more detail if you want. Other notables: * RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want...

...same road but hasn't implemented O32/N32 yet. * MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. * Many places where hasMips64*() or isGP64bit() are used in the backend. * MSA intrinsic lowering * Legalization configuration * Instruction selection * MipsTargetLowering::getOptimalMemOpType() * And many more. I can provide more detail if you want. Other notables: * RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want...

...;t implemented O32/N32 yet. · MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. · Many places where hasMips64*() or isGP64bit() are used in the backend. o MSA intrinsic lowering o Legalization configuration o Instruction selection o MipsTargetLowering::getOptimalMemOpType() o And many more. I can provide more detail if you want. Other notables: · RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if...

...same road but hasn't implemented O32/N32 yet. * MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. * Many places where hasMips64*() or isGP64bit() are used in the backend. * MSA intrinsic lowering * Legalization configuration * Instruction selection * MipsTargetLowering::getOptimalMemOpType() * And many more. I can provide more detail if you want. Other notables: * RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want...

...;t implemented O32/N32 yet. • MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. • Many places where hasMips64*() or isGP64bit() are used in the backend. o MSA intrinsic lowering o Legalization configuration o Instruction selection o MipsTargetLowering::getOptimalMemOpType() o And many more. I can provide more detail if you want. Other notables: • RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if...

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because