llvm dev - Jul 2017 - 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

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

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>