search for: targetinstrinfo

Hi, Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as...

On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? > > TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any p...

On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >> >> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they ser...

I keep getting this error upon building: > Linking CXX executable ../../bin/opt > ../../lib/libLLVMTarget.so: error: undefined reference to > 'llvm::TargetInstrInfo::getNumMicroOps(llvm::InstrItineraryData > const*, llvm::MachineInstr const*) const' > ../../lib/libLLVMTarget.so: error: undefined reference to > 'llvm::TargetInstrInfo::getInstrLatency(llvm::InstrItineraryData > const*, llvm::MachineInstr const*, unsigned int*) const' &...

...ndImpl hook for Thumb1, that folds load, indirect call to direct call tLDRpci, tBLX -> tBL. This triggered an assertion error with expensive checks turned on in MachineVerifier because the newly created tBL insn by Thumb1InstrInfo::foldMemoryOperandImpl had memory operands of LoadMI attached by TargetInstrInfo::foldMemoryOperand, which is done unconditionally: // Copy the memoperands from the load to the folded instruction. if (MI.memoperands_empty()) { NewMI->setMemRefs(MF, LoadMI.memoperands()) In this case, we don't want the memory loads to be added to MI from LoadMI. Should there be some m...

...t; Thanks for the pointer Quentin. > > I would actually be in favor for more infrastructure in MC for this kind > of things. For instance, dealing with the code layout is not something MI > is good at whereas MC is perfect. > > > Most of LLVM’s target-specific information is in TargetInstrInfo. > TargetSchedModel depends on that. I don’t understand how you would build a > performance analysis tool based on LLVM without either decompiling to MI, > or rewriting those interfaces to be based on MC. I think you have to pick > one direction or the other. > > You are right tho...

...lt;stoklund at 2pi.dk> wrote: > > On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >>> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >>> >>> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think...

...> > Thanks for the pointer Quentin. > >> I would actually be in favor for more infrastructure in MC for this kind of things. For instance, dealing with the code layout is not something MI is good at whereas MC is perfect. > > Most of LLVM’s target-specific information is in TargetInstrInfo. TargetSchedModel depends on that. I don’t understand how you would build a performance analysis tool based on LLVM without either decompiling to MI, or rewriting those interfaces to be based on MC. I think you have to pick one direction or the other. You are right those are the two choices. Given...

...ks for the pointer Quentin. >> >>> I would actually be in favor for more infrastructure in MC for this kind of things. For instance, dealing with the code layout is not something MI is good at whereas MC is perfect. >> >> Most of LLVM’s target-specific information is in TargetInstrInfo. TargetSchedModel depends on that. I don’t understand how you would build a performance analysis tool based on LLVM without either decompiling to MI, or rewriting those interfaces to be based on MC. I think you have to pick one direction or the other. > You are right those are the two choices. G...

> Okay, if you update from CVS, this problem should be fixed, at least for > the AsmPrinter. Please try it out (without AAA), and let me know if you > have problems with any other part of the code generator. The behaviour now is: The TargetInstrInfo namespace is used for the PHI instruction regardless of the presence of the AAA instruction. In ARMGenInstrNames.inc, the TargetInstrInfo namespace is used if the AAA instruction isn't defined and the ARM namespace is used if it is defined. > Thanks! > > -Chris Best Regards, Rafael

...nd so far we've managed to get it working with some nice speedups. Unlike Hexagon however, our backend doesn't generate hardware loop instructions and so all our loops are a combination of induction variables, comparisons and branches. So when it came to implementing reduceLoopCount for our TargetInstrInfo, we found that we didn't have enough information from analyzeLoop to reduce the loops. Currently the signatures look like this: bool analyzeLoop(MachineLoop &L, MachineInstr *&IndVarInst, MachineInstr *&CmpInst) unsigned TargetInstrInfo::reduceLoopCount...

...is somewhat reasonable to have calls “document” which memory slot they access. > > I am not fan of the idea of removing the addition of the memory operands because: > 1. This was part of the interface contract > 2. This may prevent unfolding to work > > For #1 see that comment on TargetInstrInfo::foldMemoryOperandImpl: > /// Target-independent code in foldMemoryOperand will > /// take care of adding a MachineMemOperand to the newly created instruction. > > For #2, I am guessing folding at one point and unfolding later is a rare enough thing that we may not care. > > C...

On Jun 8, 2012, at 12:52 PM, Marc J. Driftmeyer <mjd at reanimality.com> wrote: > I keep getting this error upon building: > >> Linking CXX executable ../../bin/opt >> ../../lib/libLLVMTarget.so: error: undefined reference to 'llvm::TargetInstrInfo::getNumMicroOps(llvm::InstrItineraryData const*, llvm::MachineInstr const*) const' >> ../../lib/libLLVMTarget.so: error: undefined reference to 'llvm::TargetInstrInfo::getInstrLatency(llvm::InstrItineraryData const*, llvm::MachineInstr const*, unsigned int*) const' >> ../../...

...ond_true.i: ; preds = %entry ret void gcov_version.exit: ; preds = %entry ret void UnifiedReturnBlock: ; preds = %entry ret void } --------------------------------------- The error is: llc: /home/rafael/dev/llvm/cvs/include/llvm/Target/TargetInstrInfo.h:317: virtual void llvm::TargetInstrInfo::InsertBranch(llvm::MachineBasicBlock&, llvm::MachineBasicBlock*, llvm::MachineBasicBlock*, const std::vector<llvm::MachineOperand, std::allocator<llvm::MachineOperand> >&) const: Assertion `0 && "Target didn't implement...

> On Mar 6, 2018, at 4:20 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > To be clear then, resolveSchedClass should be moved from TargetSchedModel into MCSchedModel (which is where I originally wanted it). Any TargetInstrInfo APIs called from SchedPredicate should be moved to MCInstrInfo, which should be straightforward but annoying. > > Personally, I don't have a strong opinion on this. > My major concern is that not all predicates can be easily rewritten/adapted to work with MCInst and MCschedModel. >...

I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps every few days or so. I've not had success in some cases building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC 4.1.1. >>> cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const llvm::TargetInstrDescriptor& llvm::TargetInstrInfo::get(llvm::MachineOpCode) const: Assertion '(unsigned)Opcode < NumOpcodes' failed. /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c: At top level: /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c:314: internal compiler error: Aborted <&lt...

...[UTF-8] Rafael Esp?ndola wrote: >> Okay, if you update from CVS, this problem should be fixed, at least for >> the AsmPrinter. Please try it out (without AAA), and let me know if you >> have problems with any other part of the code generator. > The behaviour now is: > The TargetInstrInfo namespace is used for the PHI instruction > regardless of the presence of the AAA instruction. Good, this is expected. TargetInstrInfo::PHI == ARM::PHI. > In ARMGenInstrNames.inc, the TargetInstrInfo namespace is used if the > AAA instruction isn't defined and the ARM namespace is us...

...> Yeah, sorry I'm stubborn sometimes. :-) And really I think adding the > code size functionality is not really that complicated. I would be > happy to help if you run into issues. > > What do you think of adding a TargetMachine::getFunctionSize(MachineFunction*) and a TargetInstrInfo::getInstructionSize(MachineInstruction*)? Is this a good place to make them available to other passes? (ie the JIT) Thanks, Nicolas > Thanks. > > Evan >

On Jan 23, 2009, at 3:28 AM, Mondada Gabriele wrote: > Hi, > I'm implementing storeRegToStackSlot() and, in order to store some > specific registers (floating point regs and address regs) I've to > copy them to more standard regs and copy these last ones to the slot. > I tried to generate instructions that use physical registers, but by > doing that I overwrote

...with a non-empty condition list, as that wouldn't make any sense. This leaves a natural way to represent conditional return branches. Next up is to add support to PPC for AnalyzeBranch and conditional return. Repository: rL LLVM http://reviews.llvm.org/D20841 Files: include/llvm/Target/TargetInstrInfo.h Index: include/llvm/Target/TargetInstrInfo.h =================================================================== --- include/llvm/Target/TargetInstrInfo.h +++ include/llvm/Target/TargetInstrInfo.h @@ -458,6 +458,13 @@ /// 'false' destination in FBB, and a list of operands that eval...