[llvm-dev] Hexagon, DFAPacketizer and instruction expansion

[Rail Shafigulin via llvm-dev]

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>