search for: mipssubtarget

...ntIslandPass.cpp @@ -80,6 +80,9 @@ FunctionPass *llvm::createMipsConstantIslandPass(MipsTargetMachine &tm) { } bool MipsConstantIslands::runOnMachineFunction(MachineFunction &F) { - return true; + // The intention is for this to be a mips16 only pass for now + if (!TM.getSubtarget<MipsSubtarget>().inMips16Mode()) + return false; + return false; } diff --git a/lib/Target/Mips/MipsLongBranch.cpp b/lib/Target/Mips/MipsLongBranch.cpp index 2efe534..bf5ad37 100644 --- a/lib/Target/Mips/MipsLongBranch.cpp +++ b/lib/Target/Mips/MipsLongBranch.cpp @@ -399,6 +399,8 @@ static void emitGPD...

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

Jim, You are correct: MipsSubtarget. For llvm-mc we have a straight MCSubtargetInfo object. For llc we get a MipsSubtarget object which derives from MipsGenSubtargetInfo which derives from TargetSubtargetInfo which derives from MCSubtargetInfo. The patch I hope to send out for review will do this: Add a new data member to MCSubtar...

...lone assembler such as ".options pic0" which forces non-shared relocation model. > > The direction I am going in is to add a new data member in MCSubtargetInfo that is a std::set. This set of booleans are target specific and is used as a bulletin board. This allows me to update my MipsSubtargetInfo object whenever it or a derived reference of it is available. I have a reference of SubtargetInfo in <target>ELFObjectWriter in my current patch. I don't see a definition of a MipsSubtargetInfo class in the tree. Do you mean MipsSubtarget as defined in MipsSubtarget.h? -Jim >...

...change. Cheers, Jack ________________________________________ From: Carter, Jack Sent: Tuesday, December 11, 2012 1:33 PM To: Jim Grosbach Cc: Rafael Espíndola; List Subject: RE: [LLVMdev] [MC] [llvm-mc] Getting target specific information to <target>ELFObjectWriter Jim, You are correct: MipsSubtarget. For llvm-mc we have a straight MCSubtargetInfo object. For llc we get a MipsSubtarget object which derives from MipsGenSubtargetInfo which derives from TargetSubtargetInfo which derives from MCSubtargetInfo. The patch I hope to send out for review will do this: Add a new data member to MCSubtar...

...the standalone assembler such as ".options pic0" which forces non-shared relocation model. The direction I am going in is to add a new data member in MCSubtargetInfo that is a std::set. This set of booleans are target specific and is used as a bulletin board. This allows me to update my MipsSubtargetInfo object whenever it or a derived reference of it is available. I have a reference of SubtargetInfo in <target>ELFObjectWriter in my current patch. I am open to better suggestions as long as it solves the basic issue and allows me to mark up ELF header information with fungible target spe...

Some stuff did not get pasted in properly. static MachineBasicBlock* ExpandCondMov(MachineInstr *MI, MachineBasicBlock *BB, DebugLoc dl, const MipsSubtarget *Subtarget, const TargetInstrInfo *TII, bool isFPCmp, unsigned Opc) { // There is no need to expand CMov instructions if target has // conditional moves. if (Subtarget->hasCondMov()) return BB; //...

...er example I can look at. I suppose I can mimick this if people say this just the correct way to do this in LLVM. static MachineBasicBlock* ExpandCondMov(MachineInstr *MI, MachineBasicBlock *BB, DebugLoc dl, const MipsSubtarget *Subtarget, const TargetInstrInfo *TII, bool isFPCmp, unsigned Opc) { // There is no need to expand CMov instructions if target has // conditional moves. if (Subtarget->hasCondMov()) return BB; //...

...ess of target specific data to <target>ELFObjecWriter was to pass a reference of SubtargetInfo to it through the <target>AsmBackend construction. For the integrated assembler this works well because what is really passed is a derived class of <target>Subtarget. I can add stuff to MipsSubtarget without affecting any other target. Here is the inheritance: SubtargetInfo TargetSubtargetInfo <target>GenSubtargetInfo <target>Subtarget <target>Subtarget is created through TargetMachine and is codegen centric. For the standalone assembler and the clang this isn'...

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com> wrote: > Eli, > > This is the kind of feedback I want. I believe I have to add to the base class so it should be generally useful. I can see string being better for the value. I still am enamoured with an enumeration for the tab though: int->string. How would that be a limitation? > I guess that's fine,

After discussions last night, I'm leaning towards going legit with all my pseudo expansions in Mips 16. Some I think I can clearly do by just putting in the proper side effects of implicit registers (T8 the condition code register as used by mips 16). But I'm still left with some pseudos that have jmp .+4 type instructions in them. The original Mips port was to Mips I and Mips I,

Currently it's not possible during elf generation to set eflags properly. While it's possible to create an override for the virtual function WriteEflags, the information needed is that from the TargetSubtargetInfo (or classes derived from that like MipsSubTarget) but all there is there is the basic machine type (i.e. MIPS, ARM, x86) and endian. This causes all the direct object emitters to put some fixed default into eflags. Eflags contains detailed information about the subflavor of architecture, ABI, other. One side effect of this problem is the ob...

...ow of some impending work > that it likely to make matters worse. I want to be able to, for example, ask > the TargetTuple whether I am targeting a 64-bit ISA and whether I'm supposed > to treat it as a 32-bit ISA (e.g. O32 on MIPS64R2) in many areas of LLVM > (including those where MipsSubtarget and similar are not available) and be > able to rely on the answer. At the moment, we incorrectly conflate 'is it a > 64-bit ISA?' with 'is the CPU 64-bit?' as well as 'is the ABI 64-bit?' with > 'is the ISA 64-bit?' I feel your pain. We have our own varian...

...tions are used (mips16,micromips,etc.). I shouldn't have to muck with base classes to handle esoteric target specific issues such as these. <target>ELFObjectWriteris used for direct object output whether directly from the codegen or from the llvm-mc assembler. The grand idea was to use MipsSubtarget because it has almost everything I need, but the big glitch is that is only used by llc and when used directly by llvm-mc, we only get the base class MCSubtargetInfo. AsmPrinter has access to the codegen variation (<target>Subtarget) and thus doesn't have this issue. Is the answer for e...

...very high. I also know of some impending work that it likely to make matters worse. I want to be able to, for example, ask the TargetTuple whether I am targeting a 64-bit ISA and whether I'm supposed to treat it as a 32-bit ISA (e.g. O32 on MIPS64R2) in many areas of LLVM (including those where MipsSubtarget and similar are not available) and be able to rely on the answer. At the moment, we incorrectly conflate 'is it a 64-bit ISA?' with 'is the CPU 64-bit?' as well as 'is the ABI 64-bit?' with 'is the ISA 64-bit?' > > The string serialization I mentioned above is...

Hi Daniel, > (from the context, you might have meant 'tuple' where you've written > 'triple'. I'm answering based on the assumption you meant 'triple') > > I did mean what I wrote. > The GNU triple is already used as a way of encoding a large amount of the > target data in a string but unfortunately, while this data is passed > throughout

Hi Eric, Thanks for getting back to me on this. > I'm not sure I agree with the basic idea of using the target triple as a way of > encoding all of the pieces of target data as a string. I think in a number of > cases what we need to do is either open up API to the back end to specify things, > or encode the information into the IR when it's different from the generic triple.