Supporting freeze in GlobalISel / freeze semantics in MIR

Project Infrastructure LLVM Dev List Archives
1

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] ⚙ D76483 [DivRemPairs] Freeze operands if they can be undef values
[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.

2

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

3

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]