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
with Q; use Q;
procedure P is
B : Boolean;
E : Enum;
begin
Get ("four", E, B);
if B = True then
raise Program_Error;
end if;
Get ("three", E, B);
if B = False then
raise Program_Error;
end if;
declare
A : Enum_Boolean_Array (One .. E) := (others => True);
begin
Set (A);
end;
end;
with Ada.Characters.Handling;
with Ada.Containers;
with Ada.Containers.Indefinite_Hashed_Maps;
with Ada.Strings.Hash;
package body Q is
type Enum_Name is array (Enum) of access constant String;
Enum_Name_Table : constant Enum_Name := (
One => new String'("one"),
Two => new String'("two"),
Three => new String'("three"));
package String_To_Enum_Map is new Ada.Containers.Indefinite_Hashed_Maps
(Key_Type => String, Element_Type => Enum,
Hash => Ada.Strings.Hash, Equivalent_Keys => "=");
function Fill_Hashed_Map return String_To_Enum_Map.Map is
Res : String_To_Enum_Map.Map;
use String_To_Enum_Map;
begin
for I in Enum_Name_Table'Range loop
declare
Kind : constant String := Enum_Name_Table (I).all;
begin
Res.Insert(Key => Kind, New_Item => I);
end;
end loop;
return Res;
end;
String_To_Enum : constant String_To_Enum_Map.Map := Fill_Hashed_Map;
procedure Get (Kind : String; Result : out Enum; Success : out Boolean) is
X : constant String := Ada.Characters.Handling.To_Lower (Kind);
use String_To_Enum_Map;
Curs : constant Cursor := String_To_Enum.Find (X);
begin
Success := Curs /= No_Element;
if Success then
Result := Element(Curs);
end if;
end;
procedure Set (A : Enum_Boolean_Array) is null;
end Q;
package Q is
type Enum is (One, Two, Three);
for Enum'Size use 16;
type Enum_Boolean_Array is array (Enum range <>) of Boolean;
procedure Get (Kind : String; Result : out Enum; Success : out Boolean);
procedure Set (A : Enum_Boolean_Array);
end Q;
