search for: alias_sets_conflict_p

...hy I assumed direction wasn't needed is because I thought the >> relation `alias` was symmetric: if x aliases y then y alias x in all cases. >> Is this the case for tbaa? > > It should not be, but LLVM may have done this :) > See the difference in GCC's alias.c between alias_sets_conflict_p and > alias_set_subset_of_p. > > You can see where the subset (one-way checking) is used in tree-ssa-alias.c > > If LLVM does always use this rule, and plans on keeping it that way, > you are correct that there is no point in having a directed graph at > all, since you aren...

Hi all, A while ago there was a discussion on changing the current "set of trees" representation of TBAA metadata to be more expressive, prompted by the need to support C structs. Dan Gohman also talked about the issue here: http://llvm.org/devmtg/2012-11/Gohman-AliasAnalysis.pdf. It was suggested that the trees be replaced by a type DAG then. While working on this compiler

...000006c0 l O .rodata 00000018 __FUNCTION__.20026 > +000006d8 l O .rodata 00000010 __FUNCTION__.22405 > +000006e8 l O .rodata 00000016 __FUNCTION__.22481 > 00000004 l O .data 00000004 varargs_set > 00000000 l d .comment 00000000 > 00000000 g F .text 000000e4 alias_sets_conflict_p > @@ -11617,23 +11617,23 @@ > 39c: R_386_32 gt_ggc_mx_varray_head_tag > 3a0: R_386_32 gt_pch_nx_varray_head_tag > > -000003b8 <__FUNCTION__.20147>: > +000003b8 <__FUNCTION__.20062>: > 3b8: 66 69 6e 64 5f 62 imul $0x625f,0x64(%esi),%bp > 3be: 61...

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the