Uninitialized registers handling in the REE pass

[Pierre-Marie de Rodat]

Hello,

The attached reproducer[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...

-- 
Pierre-Marie de Rodat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.adb
Type: text/x-adasrc
Size: 320 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20150706/6eb33748/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: q.adb
Type: text/x-adasrc
Size: 1411 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20150706/6eb33748/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: q.ads
Type: text/x-adasrc
Size: 268 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20150706/6eb33748/attachment-0002.bin>