llvm dev - Nov 2015 - Hexagon, DFAPacketzier and dependency pruning

DFAPacketizer has a virtual method isLegalToPruneDependencies(). I looked
at  the Hexagon code and but wasn't unable to understand the details
(unfortunately as of now, I'm not well versed in the Hexagon architecture).
Would anyone be able to shed light on what is dependency pruning and how it
should be used?

Any help is appreciated.
-- 

R
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151120/57b81339/attachment.html>

On 11/20/2015 12:52 PM, Rail Shafigulin via llvm-dev
wrote:
> DFAPacketizer has a virtual method isLegalToPruneDependencies(). I
> looked at  the Hexagon code and but wasn't unable to understand the
> details (unfortunately as of now, I'm not well versed in the Hexagon
> architecture). Would anyone be able to shed light on what is dependency
> pruning and how it should be used?
>
> Any help is appreciated.
Two instructions can be packetized if
- "isLegalToPacketizeTogether" returns true, or
- "isLegalToPruneDependencies" returns true.

The reason why two instructions may not be "legal to packetize
together"
may be that there is some form of dependency between the two.  For 
example, one instruction may define register, and the next one may use 
it.  In most cases on Hexagon, these cannot go into the same packet: all 
registers used in a packet are read before anything gets updated.  There 
are exception to this, and in some cases, instructions can go together 
despite dependencies---this is where these dependencies can get
"pruned"
(which really means "ignored").

The code in Hexagon is somewhat convoluted, in the current shape it's 
not necessarily something to imitate.  As a first approximation, you can 
just leave the "isLegalToPruneDependencies" with the default 
implementation (that returns "false").  This way only 
"isLegalToPacketizeTogether" will determine if two instructions can be
in a packet together or not.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

On Fri, Nov 20, 2015 at 2:15 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 11/20/2015 12:52 PM, Rail Shafigulin via llvm-dev wrote:
>
>> DFAPacketizer has a virtual method isLegalToPruneDependencies(). I
>> looked at  the Hexagon code and but wasn't unable to understand the
>> details (unfortunately as of now, I'm not well versed in the
Hexagon
>> architecture). Would anyone be able to shed light on what is dependency
>> pruning and how it should be used?
>>
>> Any help is appreciated.
>>
>
> Two instructions can be packetized if
> - "isLegalToPacketizeTogether" returns true, or
> - "isLegalToPruneDependencies" returns true.
>
> The reason why two instructions may not be "legal to packetize
together"
> may be that there is some form of dependency between the two.  For example,
> one instruction may define register, and the next one may use it.  In most
> cases on Hexagon, these cannot go into the same packet: all registers used
> in a packet are read before anything gets updated.  There are exception to
> this, and in some cases, instructions can go together despite
> dependencies---this is where these dependencies can get "pruned"
(which
> really means "ignored").
>
> The code in Hexagon is somewhat convoluted, in the current shape it's
not
> necessarily something to imitate.  As a first approximation, you can just
> leave the "isLegalToPruneDependencies" with the default
implementation
> (that returns "false").  This way only
"isLegalToPacketizeTogether" will
> determine if two instructions can be in a packet together or not.
>
> -Krzysztof
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

Thanks for the explanation.

-- 
R
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151120/61743bf6/attachment.html>