[Bug rtl-optimization/66790] New: Invalid uninitialized register handling in REE

[derodat at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790

            Bug ID: 66790
           Summary: Invalid uninitialized register handling in REE
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: derodat at adacore dot com
  Target Milestone: ---

The reproducer I'm about to attach[1] seems to trigger a code generation issue
at least on x86_64-linux:

    $ gnatmake -q p -O3 -gnatn
    $ ./p

    raised PROGRAM_ERROR : p.adb:9 explicit raise

The bottom line is that when Success is False in Q.Get (q.adb, around line 40)
its value is clobbered during return. If we build with -fno-ree, we can see in
the assembly code (near the return point for q__get) the following sequence:

    movzwl    (%rax), %epb
    ...
somelabel:
    ...
    movzwl    %bp, %ebp
    ...
    salq    $16, %rax
    orq    %rbp, %rax

However, without the -fno-ree switch the instruction:

    movzwl    %bp, %ebp

is merged with its definition (the first movzwl instruction) by the REE pass.
This is wrong since the definition does _not_ dominate this zero-extension: the
first movzwl instruction can be by-passed through "somelabel".

I started to investigate this issue: the REE pass is currently not aware of
this by-pass code path because it is reached by no proper definition (it brings
an uninitialized %rbp register to the zero-extension). This happens in
ree.c:get_defs; in our case (insn=second movzwl, reg=BP) DF_REF_CHAIN contains
only one definition: the movzwl instruction.

Given the "somelabel" code path, I would rather expect DF_REF_CHAIN to hold a
NULL reference to materialize the lack of initialization in one path. I found
the DF_LR_IN/DF_LR_OUT macros from df.h: they provide information about
uninitialized variables but the associated comment says they should not be used
("This intolerance should eventually be fixed."). Besides, they provide a
basic-block-level information whereas we are rather interested in
instruction-level information in REE.

I was thinking that REE may not be the only optimization pass needing this kind
of information but I found no other one, so I'm not sure how this ought to be
handled. Can anybody confirm my intuition about the NULL reference in
DF_REF_CHAIN? I'm willing to implement it but I prefer first to be sure this is
the right approach.

Thanks in advance!


[1] It's in Ada. I tried to translate it into C but any change in register
allocation makes the issue disappear...