llvm dev - Nov 2015 - Hexagon, DFAPacketizer and instruction expansion

I'm using a Hexagon's packetizer as an example to packetize instructions
for my custom VLIW. The problem that I'm facing is that my target as it
turns out doesn't have all the instructions expanded by the time
packetization happens (for example I have a RET instruction which gets
expanded into a write to a register and a jump/branch). I'm wondering if
Hexagon is experiencing the same issue and how it is solved? And if it
doesn't experience the same what would be the recommendation on solving
this problem? At the moment, my packetization pass is the last one in
MyTargetPassConfig::addPreEmitPass()

Any help is appreciated.

-- 
R
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151117/47d2419c/attachment.html>

On 11/17/2015 6:51 PM, Rail Shafigulin via llvm-dev
wrote:
> I'm using a Hexagon's packetizer as an example to packetize
instructions
> for my custom VLIW. The problem that I'm facing is that my target as it
> turns out doesn't have all the instructions expanded by the time
> packetization happens (for example I have a RET instruction which gets
> expanded into a write to a register and a jump/branch). I'm wondering
if
> Hexagon is experiencing the same issue and how it is solved? And if it
> doesn't experience the same what would be the recommendation on solving
> this problem? At the moment, my packetization pass is the last one in
> MyTargetPassConfig::addPreEmitPass()
There is a target-independent pass that will try to expand all pseudo 
instructions after register allocation.  For each instruction, it will 
check if the instructions is a pseudo-instruction, and if so, it will 
call the target hook "expandPostRAPseudo" on that instruction.

Your target will need to implement TargetInstrInfo::expandPostRAPseudo, 
and mark RET as a pseudo-instruction.

See lib/CodeGen/ExpandPostRAPseudos.cpp for the expanding pass, and the 
"expandPostRAPseudo" functions for individual targets to get an idea
of
how they work.

-Krzysztof

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

On Wed, Nov 18, 2015 at 6:44 AM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 11/17/2015 6:51 PM, Rail Shafigulin via llvm-dev wrote:
>
>> I'm using a Hexagon's packetizer as an example to packetize
instructions
>> for my custom VLIW. The problem that I'm facing is that my target
as it
>> turns out doesn't have all the instructions expanded by the time
>> packetization happens (for example I have a RET instruction which gets
>> expanded into a write to a register and a jump/branch). I'm
wondering if
>> Hexagon is experiencing the same issue and how it is solved? And if it
>> doesn't experience the same what would be the recommendation on
solving
>> this problem? At the moment, my packetization pass is the last one in
>> MyTargetPassConfig::addPreEmitPass()
>>
>
> There is a target-independent pass that will try to expand all pseudo
> instructions after register allocation.  For each instruction, it will
> check if the instructions is a pseudo-instruction, and if so, it will call
> the target hook "expandPostRAPseudo" on that instruction.
>
> Your target will need to implement TargetInstrInfo::expandPostRAPseudo,
> and mark RET as a pseudo-instruction.
>
> See lib/CodeGen/ExpandPostRAPseudos.cpp for the expanding pass, and the
> "expandPostRAPseudo" functions for individual targets to get an
idea of how
> they work.
>
> -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
>
I guess I should be more clear by what I mean "expanded". When I say
"expanded" I mean the final instruction assembly representation, i.e.
all
instructions were lowered to their assembly level. Will you recommendation
still hold or I should be considering another approach?

-- 
R
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151118/008841c8/attachment.html>