search for: instritinerarydata

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' > ../../lib/libLLVMTarget.so: error: un...

...n 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' >> ../../lib/libLLVMTarget.so: error: undefined re...

...ll refuse to hoist "cheap" instructions out of loops. By default, when an itinerary is available, this means that all of the defined operands are available in at most 1 cycle. ARM overrides this, and provides this more-customized definition: bool ARMBaseInstrInfo:: hasLowDefLatency(const InstrItineraryData *ItinData, const MachineInstr *DefMI, unsigned DefIdx) const { if (!ItinData || ItinData->isEmpty()) return false; unsigned DDomain = DefMI->getDesc().TSFlags & ARMII::DomainMask; if (DDomain == ARMII::DomainGeneral) { unsigned DefClass = DefMI->getDesc(...

...If it really helps, you could redeclare defaultDefLatency as a virtual hook and override it. (2) The "old" style of pipeline itineraries. This is closest to the old behavior. If an itinerary is defined, you get to override two hooks: virtual int TargetInstrInfo::getOperandLatency(const InstrItineraryData *ItinData, const MachineInstr *DefMI, unsigned DefIdx, const MachineInstr *UseMI, unsigned UseIdx) const; virtual unsigned TargetInstrInfo::getInstrLatency(c...

On Tue, Nov 17, 2015 at 11:15 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 11/17/2015 12:26 PM, Rail Shafigulin wrote: > >> >> I tried setting >> let mayLoad = 1 { >> class InstrLD .... { >> } >> } >> >> But that didn't seem to work. When I looked at the debug output the >> latency for the load

...ot;TTI->getInstructionLatency" if an itinerary exists, otherwise it will use the new schedule model. ATTENTION: Out of tree targets! (I will also send out an email later to LLVMDev) This means, if your target implements unsigned getInstrLatency(const InstrItineraryData *ItinData, const MachineInstr *MI, unsigned *PredCost); and returns a value for "PredCost", you now also need to implement unsigned getPredictationCost(const MachineInstr *MI); (if your target uses the...

We'd like to be able to vary the latency of our load instructions based on what address space is being loaded from. I was thinking I could do this by overriding getOperandLatency in our target, but I'm wondering if the addrspace info is available when instructions are scheduled? For example, I have this in our llvm IR: %0 = load i32 addrspace(4)* @answer, align 4 store i32 %0, i32*

...----------------------------------------------------------------------===// > + > +#ifndef _AMDGPUSUBTARGET_H_ > +#define _AMDGPUSUBTARGET_H_ > +#include "AMDILSubtarget.h" > + > +namespace llvm { > + > +class AMDGPUSubtarget : public AMDILSubtarget > +{ > + InstrItineraryData InstrItins; > + > +public: > + AMDGPUSubtarget(StringRef TT, StringRef CPU, StringRef FS) : > + AMDILSubtarget(TT, CPU, FS) > + { > + InstrItins = getInstrItineraryForCPU(CPU); > + } > + > + const InstrItineraryData &getInstrItineraryData() const { return In...

...ocessed was in Mips 16 Mode + bool PreviousInMips16Mode; + // InMicroMips -- can process MicroMips instructions bool InMicroMipsMode; // HasDSP, HasDSPR2 -- supports DSP ASE. bool HasDSP, HasDSPR2; + // Allow mixed Mips16 and Mips32 in one source file + bool AllowMixed16_32; + InstrItineraryData InstrItins; // The instance to the register info section object @@ -103,6 +113,12 @@ protected: // Relocation Model Reloc::Model RM; + // We can override the determination of whether we are in mips16 mode + // as from the command line + enum {NoOverride, Mips16Override, NoMips16Over...

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

.... >> >> Evan >> > > An N-wide machine can be described with N units, regardless of how deep the > pipeline is. > > Furthermore if you only need to model issue width, then you don't even need > to describe the pipeline at all. You only need to set the > InstrItineraryData::IssueWidth field. ARMSubtarget::computeIssueWidth does > this by assuming something about the convention of ARM itineraries. But you > could simply embed the issue width constants for your subtargets within the > target initialization code (in place of computeIssueWidth). I never bothered...

.../CodeGen/MachineBasicBlock.h" >> #include "llvm/ADT/DenseMap.h" >> +#include<map> >> >> namespace llvm { >> >> @@ -36,7 +37,7 @@ class MachineInstr; >> class MachineLoopInfo; >> class MachineDominatorTree; >> class InstrItineraryData; >> -class ScheduleDAGInstrs; >> +class DefaultVLIWScheduler; >> class SUnit; >> >> class DFAPacketizer { >> @@ -77,6 +78,8 @@ public: >> // reserveResources - Reserve the resources occupied by a machine >> // instruction and change the cu...