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

[Andrew Trick via llvm-dev]

It’s not necessary to use virtual registers or stack frame management to use MI. The point of MI is to have a common interface to LLVM backend APIs so you can query the scheduling model, register usage, a variety of TTI/STI information, analyze control flow, and analyze the call graph.

Why would you ever want to duplicate all of MI’s goodness rather than using it directly?

I was under the impression that MC -> MI has been useful in the past and that it’s something we would want to support long term.

-Andy

> On Mar 4, 2018, at 12:57 PM, Matthias Braun <matze at braunis.de> wrote:
> 
> I haven’t actually worked on analyzing assembler so take this with a grain of salt/as a less informed opinion:
> 
> But I think MachineInstrs wouldn’t bring much of a benefit over MC here: MI is designed for lowering of a higher level IR towards a machine representation; that is a different goal and comes with various things (pseudo instructions, virtual register management, stack frame management, etc.) that don’t help for this use case and rather have the potential to be in the way...
> 
> I’d rather work towards remodeling the code/datastructures to make reuse in llvm-mca simpler where it makes sense.
> 
> - Matthias
> 
>> On Mar 2, 2018, at 9:33 AM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org <mailto: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 gmail.com>> wrote:
>>> 
>>> There are a number of people on llvm-dev who can explain better than I how to decompile into MachineInstrs. I’m not totally opposed to checking in something that works with MCInstr, but this does run strongly contrary to the design of LLVM’s subtarget support.
>>> 
>>> That would be great! I would be very happy if somebody suggests how to do it (or does it for me :-)).
>> 
>> I know that’s it’s been done before, it’s an extremely useful technique, and work in that direction should be strongly encouraged. I don’t know the current state of in-tree support.
>> 
>> Ahmed?
>> 
>>> Do you think the current design (modulo the changes suggested in the review) would be acceptable to start?
>> 
>> I’ll let others review the patch. The fact that you have collaborators in the community is good enough for me.
>> 
>> -Andy
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180305/d11807ca/attachment.html>