[llvm-dev] Glue two instructions together

[Przemyslaw Ossowski via llvm-dev]

Thanks for your suggestion!
I didn't want to hardcore particular one register, like R1.
So the approach with one additional output register could help resolve my
issue

Thanks,
Przemek



On Wed, Dec 11, 2019 at 8:24 PM Craig Topper <craig.topper at gmail.com> wrote:

> Can you just have the pseudo instruction produce two values with one not
> connected to anything outside. I would think the register allocator should
> pick a register for it. Then you can just use the register when you expand
> it.
> ~Craig
>
>
> On Wed, Dec 11, 2019 at 11:06 AM Aaron Smith via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> You could hardcode a register for the pseudo instruction to use in the td
>> file.
>> The register allocator will make sure not to clobber it.
>>
>> let uses = [ R1 ], defs = [ R1 ] in {
>> def MYINST : Pseudo<>
>> }
>>
>> On Wed, Dec 11, 2019 at 10:25 AM Przemyslaw Ossowski via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >
>> > I have one more question regarding expanding pseudo instruction.
>> >
>> > These two Machine Instructions, which I mentioned earlier, have to be
>> one after another, but also have to 'communicate' using any General Purpose
>> Register
>> >
>> > For example:
>> > gpr4 INST_IN
>> > r2 INST_OUT gpr4, r1
>> >
>> > Is there any possibility to indicate that pseudo instruction, which is
>> representing these two instruction,
>> > will define and use 'internally' one additional register from 'gpr'
>> pool (except those which are ins and outs).
>> > Aa 'internal' register there might be use any of the register from
>> 'gpr' pool. I wouldn't like to indicate particular one.
>> >
>> > Expanding will occur after register allocation, so the only solution I
>> see is involving register scavenger during expanding pass.
>> > Is usage register scavenger in such case is proper or maybe there is
>> also any simpler approach?
>> >
>> > Thanks,
>> > Przemek
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Dec 10, 2019 at 6:01 PM Przemyslaw Ossowski <
>> przemyslaw.ossowski at googlemail.com> wrote:
>> >>
>> >> Thank you Krzysztof,
>> >> I used pseudo-instruction earlier, but thought there might be easier
>> solution by implementing support for that simply in TableGen files by
>> marking somehow the instructions:)
>> >>
>> >> Thanks for confirmation, that I have to do this in a such way,
>> >> Przemek
>> >>
>> >>
>> >>
>> >> On Tue, Dec 10, 2019 at 5:51 PM Krzysztof Parzyszek <
>> kparzysz at quicinc.com> wrote:
>> >>>
>> >>> Create a pseudo-instruction that represents these two, and expand it
>> into the actual instructions late, after optimizations.
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Krzysztof Parzyszek  kparzysz at quicinc.com   AI tools development
>> >>>
>> >>>
>> >>>
>> >>> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
>> Przemyslaw Ossowski via llvm-dev
>> >>> Sent: Tuesday, December 10, 2019 10:42 AM
>> >>> To: llvm-dev <llvm-dev at lists.llvm.org>
>> >>> Subject: [EXT] [llvm-dev] Glue two instructions together
>> >>>
>> >>>
>> >>>
>> >>> Hi,
>> >>>
>> >>>
>> >>>
>> >>> for DAG-to-DAG instruction selection I’ve implemented a pattern,
>> which creates from one SDNode two instructions, something like:
>> >>>
>> >>>
>> >>>
>> >>> def: Pat<(NEW_SDNODE REG:$r1),
>> >>>
>> >>>          (INST_OUT (INST_IN), REG:$r1)>;
>> >>>
>> >>>
>> >>>
>> >>> where INST_IN doesn't  accepts any inputs and INST_OUT accepts two
>> inputs - one returned by INST_IN and REG;$r1.
>> >>>
>> >>>
>> >>>
>> >>> Is there any possibility to ‘Glue’ two instruction created in a such
>> way? Maybe something similar to creation SDNodes with SDNPOutGlue,
>> SDNPInGlue) ?
>> >>>
>> >>>
>> >>>
>> >>> These two instructions INST_IN and INST_OUT have to be one after
>> another without any other inserted between them.
>> >>>
>> >>>
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Przemek
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://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/20191211/5ec809f8/attachment.html>