Dominik Montada via llvm-dev
2020-Apr-09 09:46 UTC
[llvm-dev] 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>
Juneyoung Lee via llvm-dev
2020-Apr-09 11:43 UTC
[llvm-dev] Supporting freeze in GlobalISel / freeze semantics in MIR
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>
Dominik Montada via llvm-dev
2020-Apr-09 13:01 UTC
[llvm-dev] Supporting freeze in GlobalISel / freeze semantics in MIR
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>