search for: mcschedmodel

...I`ve tried going as far down the rabbit hole as I can, I haven`t found a way to set DefaultLoopMicroOpBufferSize on a per-ISA basis or to change the generic AArch64 model. I`ve searched for anything that might create an ISA-specific default scheduling model or that might initialize the default MCSchedModel in an ISA-specific way, but I`ve come up empty. The closest I found to what I was looking for seems to be a barrier for what I am trying to do; quoting "lib/Target/AArch64/AArch64GenSubtargetInfo.inc" in a build dir.: { "generic", (const void *)&NoSchedModel }, [...

...w 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 that the actual data is in > MCSchedModel and TargetSchedModel mostly being interested in the > MCInstrDesc you can quert from an MI it seemed to me like the > easier/cleaner route to not build up MI datastructures but stay with MC > specific things. > You are right though that there is a whole bunch of callbacks in > Target...

...ring initializaition is possible (and perhaps simple and good enough), but ideally it would be better not to do this, as those strings are already in the (SystemZ)Processors.td file. * Extend ProcessorModel with a "processor model ID" that the subtarget could later retrieve? * Extend MCSchedModel instead? Or even extend MCSchedModel with the cache size / associativity directly for this case? My first thought was to just have an enum in the target and then check the CPU string (per the first bullet), but I wonder if you think there is a better way. /Jonas

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

...at. 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 that the actual data is in MCSchedModel and TargetSchedModel mostly being interested in the MCInstrDesc you can quert from an MI it seemed to me like the easier/cleaner route to not build up MI datastructures but stay with MC specific things. > You are right though that there is a whole bunch of callbacks in TargetInstrInfo that would...

...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 that the actual data is in MCSchedModel and TargetSchedModel mostly being interested in the MCInstrDesc you can quert from an MI it seemed to me like the easier/cleaner route to not build up MI datastructures but stay with MC specific things. You are right though that there is a whole bunch of callbacks in TargetInstrInfo that would need...

...y create a MCSubtargetInfo, which calls InitMCProcessorInfo. void MCSubtargetInfo::InitMCProcessorInfo(StringRef CPU, StringRef FS) { FeatureBits = getFeatures(CPU, FS, ProcDesc, ProcFeatures); if (!CPU.empty()) CPUSchedModel = &getSchedModelForCPU(CPU); else CPUSchedModel = &MCSchedModel::GetDefaultSchedModel(); } If you have -mcpu=help in your command line llc -march=<> -mcpu=help ... The help information will be printed out twice because getFeatures will printout the help info if both ProcDesc and ProcFeatures are not empty. This is not really elegent. What I am wondering...

I'm unclear how does DFAPacketizer and the scheduler know a given instruction is a load. Here is what I'm talking about Let's assume my VLIW target is described as follows: def MyTargetItineraries : ProcessorItineraries<[Slot0, Slot1], [], [ .............................. InstrItinData<RI, [InstrStage<1, [Slot0, Slot1]>]>,

...e model. It is not extensible. Instead, it checks the current subtarget configuration, and either directly queries latency tables, or calls hooks. Three possible configurations are: (1) No per-opcode tables In this case, only one helper is used: unsigned TargetInstrInfo::defaultDefLatency(const MCSchedModel *SchedModel, const MachineInstr *DefMI) const; This is currently non-virtual because it is designed to directly query the fields in the SchedMachineModel tablegen class using another hook to select high latency ops: virtual bool isHighLatencyDef(int opc...

> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > When Ahmed and I worked on the decompiler, we first targeted MC. Going to MI was more difficult and really wouldn’t have gotten us a lot of benefits. Instead, Ahmed pushed for directly decompiling to IR (look for dagger). Thanks for the pointer Quentin. > I would actually be in favor for more

> In particular, the LoadLatency is used in defaultDefLatency: > > /// Return the default expected latency for a def based on it's opcode. > unsigned TargetInstrInfo::defaultDefLatency( > const MCSchedModel &SchedModel, const MachineInstr *DefMI) const { > if (DefMI->isTransient()) > return 0; > if (DefMI->mayLoad()) > return SchedModel.LoadLatency; > if (isHighLatencyDef(DefMI->getOpcode())) > return SchedModel.HighLatency; > return 1; > } >...

Thanks Andrea for working on this! I’ve been willing to do this for quite some time now. Looks like procrastination was the right approach here ;). > On Mar 2, 2018, at 9:33 AM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +Ahmed > >> On Mar 2, 2018, at 6:42 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com <mailto:andrea.dibiagio at

Hi, I found some different discrepancy on how Subtarget is created between some arch specific TargetMachine constructor. For example, for BPF/Lanai: BPFTargetMachine::BPFTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options,