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

[Andrea Di Biagio via llvm-dev]

On Tue, Mar 6, 2018 at 5:46 PM, Andrew Trick <atrick at apple.com> wrote:

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

Thanks for the advice Andy. I will keep looking into it.

In the meantime, the patch has got a couple of accepts, and all the review
requests have been addressed.
As I mentioned in the phabricator review, I plan to create bugs for all the
relevant comments/requests to keep track of the work on llvm-mca.
If there are no further objections I am ready to commit the tool.

Thanks,
-Andrea


>
> 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/20180307/e982e3a7/attachment.html>