[llvm-dev] Supporting freeze in GlobalISel / freeze semantics in MIR

[Juneyoung Lee via llvm-dev]

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>