search for: resolveschedclass

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

...extra codegen info around those > datastructures. Either way I think this choice has to be made by whoever is > working on decompiling tools. > > - Matthias > > > Unfortunately targets have historically been building hooks into > TargetInstrInfo. > > 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 th...

...feels less clean to me with all the extra codegen info around those datastructures. Either way I think this choice has to be made by whoever is working on decompiling tools. > > - Matthias Unfortunately targets have historically been building hooks into TargetInstrInfo. 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. I just looked at the x86 target, and I’m surprised that none of the in...

> On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at apple.com <mailto: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

...39;t have a "portable" semantic. A predicate is essentially an opaque block of code, and the semantic of predicates is unknown to tablegen. Tablegen can only trust the user, and just "copy-paste" code blocks from the various predicates to an auto-generated `XXXGenSubtargetInfo::resolveSchedClass()` function. This limits our ability to reason on predicates. In particular, it makes it extremely hard (if not impossible) for tools that can only access the MC layer to reuse predicate definitions to resolve variant scheduling classes. If instead we expose the semantic of predicates to tablegen...