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

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

> On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com>
wrote:
> 
> 
> 
>> On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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.
That’s exactly how I approached things when I was printing some stats in
assembly :). Things were readily accessible through MC.
> 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/800d4ccb/attachment-0001.html>

> On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com>
wrote:
> 
> 
> 
>> On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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

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 tree x86
machine models are using SchedPredicate, so this isn't really a limitation
for the current incarnation of the MCA tool.

-Andy

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

On Tue, Mar 6, 2018 at 5:55 AM, Andrew Trick via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Mar 5, 2018, at 6:28 PM, Matthias Braun <mbraun at apple.com>
wrote:
>
>
>
> 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>
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
>
>
> 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 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 just looked at the x86 target, and I’m surprised that none of the in
> tree x86 machine models are using SchedPredicate, so this isn't really
a
> limitation for the current incarnation of the MCA tool.
>
Yes. Luckily x86 doesn't use predicates...

> -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/20180306/3c91ecc5/attachment.html>