Rail Shafigulin via llvm-dev
2015-Nov-19 00:02 UTC
[llvm-dev] Hexagon, DFAPacketizer and instruction expansion
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>
Krzysztof Parzyszek via llvm-dev
2015-Nov-19 15:30 UTC
[llvm-dev] Hexagon, DFAPacketizer and instruction expansion
On 11/18/2015 6:02 PM, Rail Shafigulin wrote:> > 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?For dealing with cases like the RET instruction you described earlier---yes, the post-RA pseudo instruction expansion is the right place to do it. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Bruce Hoult via llvm-dev
2015-Nov-20 10:20 UTC
[llvm-dev] Hexagon, DFAPacketizer and instruction expansion
Sorry to butt in .. but curious ... "a RET instruction which gets expanded into a write to a register and a jump/branch" If you do that after Register Allocation then where do you get the temporary register from? Not knowing the architecture in question at all, maybe there's a dedicated one, in which case fine. But if not? On Thu, Nov 19, 2015 at 6:30 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 11/18/2015 6:02 PM, Rail Shafigulin wrote: > >> >> 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? >> > > For dealing with cases like the RET instruction you described > earlier---yes, the post-RA pseudo instruction expansion is the right place > to do it. > > > -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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151120/374b9e27/attachment.html>