Verena Beckham via llvm-dev
2017-Jul-26 11:50 UTC
[llvm-dev] isSSA computation in MIR parser
Hi, I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form. These tests now fail because some of our passes can be called before and after SSA, so take the wrong branches. Surely the isSSA computation is not comprehensive? It also doesn't take into account non-SSA tests which use virtual registers but happen to not assign twice to each. Duplicate assignments imply not-SSA, but no duplicate (virtual reg) assignments doesn't imply SSA? I noticed a Hexagon test (CodeGen/Hexagon/expand-condsets-rm-reg.mir) has a hack around this by inserting an additional COPY to a register, but that shouldn't be required. It means tests that are generated using llc might be failing because they are wrongly identified as SSA. Thanks, -- Verena Beckham Senior Principal Software Engineer, Compilers Codeplay Software Ltd Level C, Argyle House, 3 Lady Lawson Street, Edinburgh, EH3 9DR Tel: 0131 466 0503 Fax: 0131 557 6600 Website: http://www.codeplay.com This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated. As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments. Company registered in England and Wales, number: 04567874 Registered office: Regent house, 316 Beulah Hill, London, United Kingdom, SE19 3HF
Matthias Braun via llvm-dev
2017-Jul-26 17:05 UTC
[llvm-dev] isSSA computation in MIR parser
This should rather be solved by configuring your pass (i.e. use a common base class and create two passes from it), so you can clearly see the difference between pre- and post-ra based on the pass you are running. Determining the position in the pipeline based on flags in the machinefunction is a bad solution IMO. - Matthias> On Jul 26, 2017, at 4:50 AM, Verena Beckham via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form. These tests now fail because some of our passes can be called before and after SSA, so take the wrong branches. > Surely the isSSA computation is not comprehensive? It also doesn't take into account non-SSA tests which use virtual registers but happen to not assign twice to each. > Duplicate assignments imply not-SSA, but no duplicate (virtual reg) assignments doesn't imply SSA? > I noticed a Hexagon test (CodeGen/Hexagon/expand-condsets-rm-reg.mir) has a hack around this by inserting an additional COPY to a register, but that shouldn't be required. It means tests that are generated using llc might be failing because they are wrongly identified as SSA. > > Thanks, > > -- > Verena Beckham > > Senior Principal Software Engineer, Compilers > > Codeplay Software Ltd > Level C, Argyle House, 3 Lady Lawson Street, Edinburgh, EH3 9DR > Tel: 0131 466 0503 > Fax: 0131 557 6600 > Website: http://www.codeplay.com > > This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated. > As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments. > Company registered in England and Wales, number: 04567874 > Registered office: Regent house, 316 Beulah Hill, London, United Kingdom, SE19 3HF > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Quentin Colombet via llvm-dev
2017-Jul-26 17:15 UTC
[llvm-dev] isSSA computation in MIR parser
As an example of what Matthias is suggesting, you can look at how we did that for the MachineCopyPropagation pass in https://reviews.llvm.org/D30751 (MachineCopyPropagation vs. MachineCopyPropagationPreRegRewrite).> On Jul 26, 2017, at 10:05 AM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This should rather be solved by configuring your pass (i.e. use a common base class and create two passes from it), so you can clearly see the difference between pre- and post-ra based on the pass you are running. Determining the position in the pipeline based on flags in the machinefunction is a bad solution IMO. > > - Matthias > >> On Jul 26, 2017, at 4:50 AM, Verena Beckham via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I noticed that a while ago the isSSA flag was removed from MIR, and this property is now computed. However, the deduction only checks the virtual registers (whether they are assigned to more than once). Now I have MIR tests which live after RA, so they only contain physical registers, so the parser determines they are in SSA form. These tests now fail because some of our passes can be called before and after SSA, so take the wrong branches. >> Surely the isSSA computation is not comprehensive? It also doesn't take into account non-SSA tests which use virtual registers but happen to not assign twice to each. >> Duplicate assignments imply not-SSA, but no duplicate (virtual reg) assignments doesn't imply SSA? >> I noticed a Hexagon test (CodeGen/Hexagon/expand-condsets-rm-reg.mir) has a hack around this by inserting an additional COPY to a register, but that shouldn't be required. It means tests that are generated using llc might be failing because they are wrongly identified as SSA. >> >> Thanks, >> >> -- >> Verena Beckham >> >> Senior Principal Software Engineer, Compilers >> >> Codeplay Software Ltd >> Level C, Argyle House, 3 Lady Lawson Street, Edinburgh, EH3 9DR >> Tel: 0131 466 0503 >> Fax: 0131 557 6600 >> Website: http://www.codeplay.com >> >> This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated. >> As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments. >> Company registered in England and Wales, number: 04567874 >> Registered office: Regent house, 316 Beulah Hill, London, United Kingdom, SE19 3HF >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > 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/20170726/b2e8231b/attachment.html>