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

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 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.
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 lot of benefits. Instead,
Ahmed pushed for directly decompiling to IR (look for dagger).

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.
> 
> 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
> 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/8dab2034/attachment.html>

> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <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 lot of benefits.
Instead, Ahmed pushed for directly decompiling to IR (look 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 was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180305/266c856a/attachment.html>

> 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 lot of benefits.
Instead, Ahmed pushed for directly decompiling to IR (look 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.
You are right those are the two choices. Given that the actual data is in
MCSchedModel and TargetSchedModel mostly being interested in the MCInstrDesc you
can quert from an MI it seemed to me like the easier/cleaner route to not build
up MI datastructures but stay with MC specific things.
You are right though that there is a whole bunch of callbacks in TargetInstrInfo
that would need alternatives if we want to go this route. Indeed building up MI
makes things fit in better with the APIs today, it just 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180305/d4d51328/attachment.html>