search for: targetschedmodel

...s 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 that the actual da...

...r 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 that the actu...

...#39;computeLatency' and > 'computeOperandLatency'. However, these methods have been removed from > 'ScheduleDAG' and 'ScheduleDAGInstrs' so are no longer invoked on our > implementation. Instead, the correct approach seems to implement a > sub-class of 'TargetSchedModel'. > > When I had a look at how other targets dealt with this transition I found > that none of them had implemented the latency scheduler the way we had, so I > couldn't just mimic a strategy used by other targets moving from v3.1 to > v3.2. Unfortunately the people who imp...

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

...for dagger). 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. -Andy -------------- next part -------------- An HTML attachment...

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

...he virtual methods 'computeLatency' and 'computeOperandLatency'. However, these methods have been removed from 'ScheduleDAG' and 'ScheduleDAGInstrs' so are no longer invoked on our implementation. Instead, the correct approach seems to implement a sub-class of 'TargetSchedModel'. When I had a look at how other targets dealt with this transition I found that none of them had implemented the latency scheduler the way we had, so I couldn't just mimic a strategy used by other targets moving from v3.1 to v3.2. Unfortunately the people who implemented the existing sol...

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

I am stuck trying to adapt my out-of-target implementation to build on SVN head (actually the v3.8 branch, rev #257626). This is currently working on the v3.7.1 sources, but the changes to 'llvm::ScheduleDAGInstrs' have me stumped as to how to revise my implementation to track the changes to this class. Our 'SHAVEAsmScheduler' derives from 'ScheduleDAGInstrs' and uses

...essor, but I think it’s too heavy-weight to go in the scheduler. Maybe someday it can be an analysis tool.) let BufferSize = 0 { def HWVMEM : ProcResource<15>; } Now since you’ll want to plugin your own scheduling strategy, how you interpret the machine model is mostly up to you. What the TargetSchedModel interface does for you is normalize the resources to processor cycles. This is exposed with scaling factors (to avoid division): getResourceFactor, getMicroOpFactor, getLatencyFactor. So if you have def HW1 : ProcResource<15>; def HW2 : ProcResource<3>; LatencyFactor=15 ResourceFac...

Hi, I'm working on defining a SchedMachineModel for the Southern Islands family of GPUs, and I have two questions related to the MachineScheduler. 1. I have a resource that can process 15 instructions at the same time. In the TableGen definitions, should I do: def HWVMEM : ProcResource<15>; or let BufferSize = 15 in { def HWVMEM : ProcResource<1>; } 2. Southern Islands has

...reating a path in MachinePipeliner that does not use DFAPacketizer (b) making MachinePipeliner inheritable so that anyone can write code that does not use DFAPacketizer Since implementations using only Instruction itineraries without DFAPacketizer are possible, I don't think that I can use TargetSchedModel::hasInstrItineraries to select the execution path. Personally, I think that implementation of (b) is better. Also, if predicated instructions like SVE are available, prologue and epilogue code generation using predicated execution as shown in the reference[1] may be possible. In this case, if we c...