On Mon, 24 Jun 2019, Jan Hubicka wrote:
> Hi,
> as discussed on IRC today, after all this patch should be correct. I
> have re-tested it with x86_64-linux in the following variant which also
> moves load of ptrtype1 that is unnecesarily early.
>
> Bootstrapped/regtested x86_64-linux, OK?
OK.
R
Hi,
as discussed on IRC today, after all this patch should be correct. I
have re-tested it with x86_64-linux in the following variant which also
moves load of ptrtype1 that is unnecesarily early.
Bootstrapped/regtested x86_64-linux, OK?
* tree-ssa-alias.c (indirect_ref_may_alias_decl_p):
> I think the patch is correct. Consider the decl being accessed
> via memcpy which will result in base2_alias_set == 0. The
> GIMPLE memory model says decls are just random storage and thus
> their dynamic type can change. This is also why there's the
> "strange" (and also incomplete...) give-u
On Sat, 1 Jun 2019, Jan Hubicka wrote:
> Hi,
> while looking for the reason for extra disambiguations in
> aliasing_component_refs I have noticed an odd case. We newly disambiguate:
>
> MEM[(Element_t *)_27 + 4B];
>
> s.globalIDDataBase_m;
>
> type size
> unit-size
>
Hi,
while looking for the reason for extra disambiguations in
aliasing_component_refs I have noticed an odd case. We newly disambiguate:
MEM[(Element_t *)_27 + 4B];
s.globalIDDataBase_m;
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x770fb5
