On Wed, Mar 23, 2016 at 05:04:39PM +0100, Olivier Hainque wrote:
> The reason why 894 is not accounted in the base ref computation is because it
> is part of the epilogue sequence, and init_alias_analysis has:
>
> /* Walk the insns adding values to the new_reg_base_value array. */
> for (i = 0; i < rpo_cnt; i++)
> { ...
> if (could_be_prologue_epilogue
> && prologue_epilogue_contains (insn))
> continue;
>
> The motivation for this is unclear to me.
https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00048.html
> My rough understanding is that we probably really care about frame_related
> insns only here, at least on targets where the flag is supposed to be set
> accurately.
Also, possibly just prologue insns. So you might be able to modify
init_alias_analysis just to ignore the prologue and skip any need for
yet another hook.
Let's see what rth thinks. He did say the patch might need to be
redone. :)
https://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00072.html
[snip]
> So, aside from the dependency issue which needs to be fixed somehow, I
> think it would make sense to consider using a strong blockage mecanism in
> expand_epilogue.
That's what we both said here
https://gcc.gnu.org/ml/gcc-patches/2011-11/msg01180.html
and David agreed too
https://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html
but if you can have the alias analysis changes accepted that would be
even better.
--
Alan Modra
Australia Development Lab, IBM
