[llvm-dev] [RFC] llvm-mca: a static performance analysis tool

[Andrew Trick via llvm-dev]

> 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.
> 
> Predicates can potentially access information which is not normally reachable through the MCSchedModel interface. For example, predicate code coud use the TargetInstrInfo interface to obtain extra description for MachineInst objects. This is what happens for ARM targets, where the `PredicateProlog` casts the TargetInstrInfo object to a ARMBaseInstInfo, and predicated use the ARMBaseInstrInfo interface.
> Some predicates defined by the cortex-a9 scheduling model select the scheduling class "based on the number of memory addresses in the LDM MachineInstr". Emulating that query would require extra knowledge on the machine memory operands, which we don't have when manipulating MCInst objects.

I imagine the thing to do is keep a TTI resolveSchedClass that only handles pseudos and call down to MC for everything else. That would allow incremental migration.

I think the LDM predicate is a hack that would be great to fix—the info should all be provided by MC--but admittedly isn’t that straightforward.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/979cf1a5/attachment.html>