get_alias_set and internally record_component_aliases makes
assumptions about the IR that are only valid in RTL. As a consequence
the constant 1 is propagated into the function call in the example
below (I found this issue with 4.1 but it is also present on trunk):
struct s
{
long long a:12;
long long b:12;
long long c:40;
};
struct s s, *p = &s;
f ()
{
p->a = 1;
s.a = 2;
s.b = 3;
use (p->a, s.b);
}
or with VOPS:
# VUSE <p_7(D)>
p.0_1 = p;
# SMT.7_9 = VDEF <SMT.7_8(D)> <----- missing SFT.2 VDEF
p.0_1->a = 1;
# SFT.2_11 = VDEF <SFT.2_10(D)>
s.a = 2;
# SFT.1_13 = VDEF <SFT.1_12(D)>
s.b = 3;
# p_14 = VDEF <p_7(D)>
# SFT.1_15 = VDEF <SFT.1_13>
# SFT.2_16 = VDEF <SFT.2_11>
# SMT.7_17 = VDEF <SMT.7_9>
use (1, 3) [tail call];
In RTL the expmed.c functions extract_bit_field and store_bit_field
change the alias set of a bit-extraction or bit-insertion expression
of a memory operand to 0 because the actual RTL generated will access
adjacent fields. Therefore there is no need to represent alias-subset
relationship between non-addressable fields and their containing
structure and record_component_aliases will skip such fields.
First I was trying to remove this assumption even for RTL but that
increased memory consumption on the cc1 preprocessed files by 1%.
The other idea I had was to make this check dependent on the IR type.
The problem is that the function tree_register_cfg_hooks setting the
IR type is called only after gimplification whereas get_alias_set is
called during. Would it be acceptable to call tree_register_cfg_hooks
earlier? Hopefully, this will be a minimal change and would make it
easy to backport it to 4.1 and 4.2.
Another option would be to have a Tree-SSA-specific version of
get_alias_set and change all the invocations in the tree-* modules.
Do people have other recommendations or a preference?
Adam
