> > Well, to me "weaker" means "makes more conservative assumptions", > which in this context would be assuming a conflict in cases where > the old code didn't (i.e. returning -1 more often). I'm not sure > whether the first patch was strictly weaker in that sense, since > if the symbol_refs were not equal according to rtx_equal_for_memref_p, > the old code would fall through to the end of the function and return -1. > > >> I agree there are other refinements you can do on top of that, > >> e.g. that two block symbols in different blocks can never conflict. > >> But the patch seems to be treating anchors as an exception to the rule, > >> whereas I think they're just one instance of the rule. > > > > Can you think of some testcase? > > Not a specific one, sorry, but it seems like the kind of thing that > could happen with extra ABI-mandated constructs. > > But maybe the lack of a specific testcase is a good thing. If in practice > anchors make up the vast majority of cases where (a) SYMBOL_REF_DECL > is null and (b) XSTR is too weak, there should no harm in relying on > the old XSTR comparison for the non-anchor null-decl cases. > > > Doing XSTR==XSTR test and assuming a conflict otherwise will cause a > > conflict between > > every external variable read/write and static variable read/write as one > > will be anchored > > and other not. > > Yeah, I think handling anchors is a good thing. It just seems that > logically the correctness fix is to replace: > > /* Label and normal symbol are never the same. */ > if (x_decl != y_decl) > return 0; > return offset_overlap_p (c, xsize, ysize); > > with something like: > > if (XSTR (x, 0) == XSTR (y, 0)) > return offset_overlap_p (c, xsize, ysize); > /* Symbols might conflict. */ > return -1; > > Handling anchors would then be a very useful optimisation on top of that.
Ah, OK, now I get your point :) Yep, I have no problem beling conservative for non-anchor cases !SYMBOL_REF_DECL case. Pretty much all cases that matter are IMO either anchors or SYMBOL_REF_DECL != NULL. (i.e. user variables). I will update the patch and also look into the Alpha AND issues. Honza > > Thanks, > Richard
