> I think pseudo-instructions should also define isPseudo = 1Ah yes, thank you.> I expect that before your custom inserter, the value produced by your pseudo instruction was in a vreg. You just have to reuse this vreg to put the result of your "stuff". > If you run llc with --print-before-all, you should be able to see the actual sequence.That's exactly my problem. How to know before my custom inserter where the produced value will be? I found some documentation about the x86 target saying that the operand 0 is always the destination value, is it right? Also, sometimes I saw _getOperand(0).getReg()_, but how can I be sure that the destination will be in a vreg? Should I specify it explicitly in the TableGen definition? I admit being a bit lost inside the backend... Thank you for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150428/dcc7c9ce/attachment.html>
> On Apr 28, 2015, at 4:02 AM, Jobin, Gaël <gael.jobin at switzerlandmail.ch> wrote: > >> I think pseudo-instructions should also define isPseudo = 1 > > Ah yes, thank you. > >> I expect that before your custom inserter, the value produced by your pseudo instruction was in a vreg. You just have to reuse this vreg to put the result of your "stuff". >> If you run llc with —print-before-all, you should be able to see the actual sequence. > > > That's exactly my problem. How to know before my custom inserter where the produced value will be? I found some documentation about the x86 target saying that the operand 0 is always the destination value, is it right? Also, sometimes I saw getOperand(0).getReg(), but how can I be sure that the destination will be in a vreg? Should I specify it explicitly in the TableGen definition?Yes the first operands are the destinations (MI can produce multiple values). The instruction selector will always use a vreg to select your instruction, you don’t have anything to do. The custom inserter is executed before register allocation, and it is the role of the RA to turn the vreg into a physical one, The physical registers that you can see at this point are mainly here to implement the ABI AFAIK. — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150428/6afd4012/attachment.html>
> On Apr 28, 2015, at 7:42 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 28, 2015, at 4:02 AM, Jobin, Gaël <gael.jobin at switzerlandmail.ch <mailto:gael.jobin at switzerlandmail.ch>> wrote: >> >>> I think pseudo-instructions should also define isPseudo = 1 >> >> Ah yes, thank you. >> >>> I expect that before your custom inserter, the value produced by your pseudo instruction was in a vreg. You just have to reuse this vreg to put the result of your "stuff". >>> If you run llc with —print-before-all, you should be able to see the actual sequence. >> >> >> That's exactly my problem. How to know before my custom inserter where the produced value will be? I found some documentation about the x86 target saying that the operand 0 is always the destination value, is it right? Also, sometimes I saw getOperand(0).getReg(), but how can I be sure that the destination will be in a vreg? Should I specify it explicitly in the TableGen definition? > > Yes the first operands are the destinations (MI can produce multiple values). > > The instruction selector will always use a vreg to select your instruction, you don’t have anything to do. > The custom inserter is executed before register allocation, and it is the role of the RA to turn the vreg into a physical one, > > The physical registers that you can see at this point are mainly here to implement the ABI AFAIK.I should also add that I don’t know what you’re trying to achieve, but keep in mind that some scheduling and optimizations will run after this point. Depending on the end result you are seeking, you might need to your expansion later. — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150428/37f4df81/attachment.html>