On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou <ebotca...@adacore.com> wrote: >> fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM. >> So in these cases fixed_scalar_and_varying_struct_p effectively becomes >> a no-op on targets that don't allow MEMs in addresses and takes on >> suspicious semantics for those that do. In the former case, every >> address is treated as "unvarying" and f_s_a_v_s_p always returns null. >> In the latter case, things like REG addresses are (wrongly) treated as >> unvarying while a MEM address might correctly be treated as varying, >> leading to false positives. >> >> It looks like this goes back to when fixed_scalar_and_varying_struct_p >> was added in r24759 (1999). > > Does this mean that MEM_IN_STRUCT_P and MEM_SCALAR_P have also been > effectively > disabled since then? > >> AIUI, the true_dependence varies_p parameter exists for the benefit >> of CSE, so that it can use its local cse_rtx_varies_p function. >> All other callers should be using rtx_varies_p instead. Question is, >> should I make that change, or is it time to get rid of >> fixed_scalar_and_varying_struct_p instead? > > I'd vote for the latter (and for eliminating MEM_IN_STRUCT_P and MEM_SCALAR_P > in the process, if the answer to the above question is positive), there is no > point in resurrecting this now IMO.
I agree. The tree level routines should be able to figure most of, if not all, cases on their own via rtx_refs_may_alias_p (similar to the nonoverlapping_component_refs case which we could simply delete as well). Richard. > -- > Eric Botcazou
