llvm dev - Apr 2020 - Supporting freeze in GlobalISel / freeze semantics in MIR

Hi all,

After a recent upstream merge into our downstream sources we are 
suddenly encountering the freeze instruction in LLVM IR for div/rem 
pairs. This seems to be related to [1].

Our downstream target is GlobalISel only and unfortunately GlobalISel 
doesn't support this instruction yet, so most of our internal test-suite 
is now breaking due to GlobalISel not being able to translate this 
instruction to MIR. We would like to add support for that, but it seems 
that it is not yet clear how this freeze instruction is supposed to look 
like in MIR.

In [2], which introduced the FREEZE node to SelectionDAG, there was a 
lengthier discussion which concluded that for now proper handling was 
only added to SelDAG and the MIR related patches would be left for a 
follow up. We would like to accelerate this follow up, because we 
obviously want to get our downstream backend working again.

One part of this discussion concerned how freeze should behave on MIR 
level. Especially if there needs to be a MIR FREEZE instruction and 
whether the semantics of IMPLICIT_DEF need to be changed.

In SelectionDAG, FREEZE is currently handled as a simple COPY. This 
seems to me like SelectionDAG ignores the semantics of FREEZE, since 
COPY has other semantics? Also, would this be acceptable for the 
GlobalISel IRTranslator (even if only as a first step)?

Best regards,

Dominik

[1] https://reviews.llvm.org/D76483
[2] https://reviews.llvm.org/D29014

P.S.: is there really no way to disable a single pass from command line? 
We would like to disable the DivRemPairs pass as a first workaround.

-- 
----------------------------------------------------------------------
Dominik Montada                   Email: dominik.montada at hightec-rt.com
HighTec EDV-Systeme GmbH          Phone: +49 681 92613 19
Europaallee 19                    Fax:   +49-681-92613-26
D-66113 Saarbrücken               WWW: http://www.hightec-rt.com

Managing Director: Vera Strothmann
Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient please notify the sender immediately
and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
---

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5409 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200409/62e6c332/attachment.bin>

Hello Dominik,

As you mentioned, I suggest converting it to COPY now when lowering to
GlobalISel.

The later pipeline of freeze was intentionally left as lowered into COPY
right now, because
(1) There was a suggestion that we can simply make IMPLICIT_DEF yield the
same value whenever it was read (currently it is allowed for IMPLICIT_DEF
to return different values whenever read).
This means that FREEZE in MIR isn't needed, and lowering FREEZE to COPY
becomes sound.
(2) Existing optimizations in the upper level aren't friendly with the new
instruction, and teaching them seemed a high priority to me.

Regarding the future work for lowering the instruction into MIR, there is
no clear winner for which strategy to take yet:
If IMPLICIT_DEF can yield different values whenever read, this allows
generation of better assembly, but requires introduction of FREEZE into MIR.
If reading the IMPLICIT_DEF register yields the same value, its semantics
becomes clearer/easier & FREEZE is not needed in MIR, but codegen may not
be optimal.

Changes in GlobalISel should have been in the patch, but it was omitted.
I'm sorry for that happening.

Thanks,
Juneyoung Lee

On Thu, Apr 9, 2020 at 6:47 PM Dominik Montada via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> After a recent upstream merge into our downstream sources we are
> suddenly encountering the freeze instruction in LLVM IR for div/rem
> pairs. This seems to be related to [1].
>
> Our downstream target is GlobalISel only and unfortunately GlobalISel
> doesn't support this instruction yet, so most of our internal
test-suite
> is now breaking due to GlobalISel not being able to translate this
> instruction to MIR. We would like to add support for that, but it seems
> that it is not yet clear how this freeze instruction is supposed to look
> like in MIR.
>
> In [2], which introduced the FREEZE node to SelectionDAG, there was a
> lengthier discussion which concluded that for now proper handling was
> only added to SelDAG and the MIR related patches would be left for a
> follow up. We would like to accelerate this follow up, because we
> obviously want to get our downstream backend working again.
>
> One part of this discussion concerned how freeze should behave on MIR
> level. Especially if there needs to be a MIR FREEZE instruction and
> whether the semantics of IMPLICIT_DEF need to be changed.
>
> In SelectionDAG, FREEZE is currently handled as a simple COPY. This
> seems to me like SelectionDAG ignores the semantics of FREEZE, since
> COPY has other semantics? Also, would this be acceptable for the
> GlobalISel IRTranslator (even if only as a first step)?
>
> Best regards,
>
> Dominik
>
> [1] https://reviews.llvm.org/D76483
> [2] https://reviews.llvm.org/D29014
>
> P.S.: is there really no way to disable a single pass from command line?
> We would like to disable the DivRemPairs pass as a first workaround.
>
> --
> ----------------------------------------------------------------------
> Dominik Montada                   Email: dominik.montada at hightec-rt.com
> HighTec EDV-Systeme GmbH          Phone: +49 681 92613 19
> Europaallee 19                    Fax:   +49-681-92613-26
> D-66113 Saarbrücken               WWW: http://www.hightec-rt.com
>
> Managing Director: Vera Strothmann
> Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222
>
> This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient please notify the sender immediately
> and destroy this e-mail. Any unauthorised copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden.
> ---
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200409/17e6f642/attachment.html>

Hi,

thanks for reaching out so quickly. I have prepared a very tiny patch 
which adds translation support for freeze in GlobalISel in [1].

Obviously this will need to be updated once the further semantics of 
freeze on MIR level have been decided. But since SelDAG does the same 
and needs the same handling, this shouldn't pose a problem in my opinion.

Cheers,

Dominik

[1] https://reviews.llvm.org/D77795

Am 09.04.20 um 13:43 schrieb Juneyoung Lee:
> Hello Dominik,
>
> As you mentioned, I suggest converting it to COPY now when lowering to 
> GlobalISel.
>
> The later pipeline of freeze was intentionally left as lowered into 
> COPY right now, because
> (1) There was a suggestion that we can simply make IMPLICIT_DEF yield 
> the same value whenever it was read (currently it is allowed for 
> IMPLICIT_DEF to return different values whenever read).
> This means that FREEZE in MIR isn't needed, and lowering FREEZE to 
> COPY becomes sound.
> (2) Existing optimizations in the upper level aren't friendly with the 
> new instruction, and teaching them seemed a high priority to me.
>
> Regarding the future work for lowering the instruction into MIR, there 
> is no clear winner for which strategy to take yet:
> If IMPLICIT_DEF can yield different values whenever read, this allows 
> generation of better assembly, but requires introduction of FREEZE 
> into MIR.
> If reading the IMPLICIT_DEF register yields the same value, its 
> semantics becomes clearer/easier & FREEZE is not needed in MIR, but 
> codegen may not be optimal.
>
> Changes in GlobalISel should have been in the patch, but it was 
> omitted. I'm sorry for that happening.
>
> Thanks,
> Juneyoung Lee
>
> On Thu, Apr 9, 2020 at 6:47 PM Dominik Montada via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     Hi all,
>
>     After a recent upstream merge into our downstream sources we are
>     suddenly encountering the freeze instruction in LLVM IR for div/rem
>     pairs. This seems to be related to [1].
>
>     Our downstream target is GlobalISel only and unfortunately GlobalISel
>     doesn't support this instruction yet, so most of our internal
>     test-suite
>     is now breaking due to GlobalISel not being able to translate this
>     instruction to MIR. We would like to add support for that, but it
>     seems
>     that it is not yet clear how this freeze instruction is supposed
>     to look
>     like in MIR.
>
>     In [2], which introduced the FREEZE node to SelectionDAG, there was a
>     lengthier discussion which concluded that for now proper handling was
>     only added to SelDAG and the MIR related patches would be left for a
>     follow up. We would like to accelerate this follow up, because we
>     obviously want to get our downstream backend working again.
>
>     One part of this discussion concerned how freeze should behave on MIR
>     level. Especially if there needs to be a MIR FREEZE instruction and
>     whether the semantics of IMPLICIT_DEF need to be changed.
>
>     In SelectionDAG, FREEZE is currently handled as a simple COPY. This
>     seems to me like SelectionDAG ignores the semantics of FREEZE, since
>     COPY has other semantics? Also, would this be acceptable for the
>     GlobalISel IRTranslator (even if only as a first step)?
>
>     Best regards,
>
>     Dominik
>
>     [1] https://reviews.llvm.org/D76483
>     [2] https://reviews.llvm.org/D29014
>
>     P.S.: is there really no way to disable a single pass from command
>     line?
>     We would like to disable the DivRemPairs pass as a first workaround.
>
>     -- 
>     ----------------------------------------------------------------------
>     Dominik Montada                   Email:
>     dominik.montada at hightec-rt.com <mailto:dominik.montada at
hightec-rt.com>
>     HighTec EDV-Systeme GmbH          Phone: +49 681 92613 19
>     Europaallee 19                    Fax:   +49-681-92613-26
>     D-66113 Saarbrücken               WWW: http://www.hightec-rt.com
>
>     Managing Director: Vera Strothmann
>     Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222
>
>     This e-mail may contain confidential and/or privileged information. If
>     you are not the intended recipient please notify the sender
>     immediately
>     and destroy this e-mail. Any unauthorised copying, disclosure or
>     distribution of the material in this e-mail is strictly forbidden.
>     ---
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> -- 
>
> Juneyoung Lee
> Software Foundation Lab, Seoul National University
-- 
----------------------------------------------------------------------
Dominik Montada                   Email: dominik.montada at hightec-rt.com
HighTec EDV-Systeme GmbH          Phone: +49 681 92613 19
Europaallee 19                    Fax:   +49-681-92613-26
D-66113 Saarbrücken               WWW: http://www.hightec-rt.com

Managing Director: Vera Strothmann
Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient please notify the sender immediately
and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200409/ac59f47c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5409 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200409/ac59f47c/attachment-0001.bin>