Great, thanks -- I should have re-checked bugzilla after we tracked
this down.
We also noticed a few minor performance issues along the way.
It would be better if merge_memattrs did a min/max thing with
offset/size to choose an offset and size that encompass both original
references, rather than giving up on the offset altogether when the
offsets don't match exactly.
Also, flow_find_cross_jump coarsens the aliasing information as it
scans, so even if it gives up because it doesn't find enough insns to
merge, the aliasing data is lost. We implemented a split of the scan
from the actual destructive merging.
-Mat
Steven Bosscher <stevenb....@gmail.com> writes:
> On Mon, Apr 12, 2010 at 6:57 PM, Mat Hostetter <mhostet...@tilera.com> wrote:
> > try_crossjump_bb identifies some common insns in SPEC2000.eon and uses
> > merge_memattrs to merge them. To do so, it has to unify their
> > aliasing data such that any insn that aliased either of the original
> > insns aliases the merged insn. In our case we have two
> > identical-looking insns that are actually referencing different stack
> > spill slots, so their MEM_OFFSETs are different. merge_memattrs
> > correctly NULLs out the MEM_OFFSET of the merged insn to indicate it's
> > not sure what the offset is, although it leaves a non-NULL MEM_SIZE:
> >
> > else if (MEM_OFFSET (x) != MEM_OFFSET (y))
> > {
> > set_mem_offset (x, 0);
> > set_mem_offset (y, 0);
> > }
> >
> > Later, nonoverlapping_memrefs_p decides that this merged insn does not
> > alias another spill slot insn (one which has a valid MEM_OFFSET), but
> > in fact they do alias. The scheduler then creates an incorrect schedule.
>
> Sounds like http://gcc.gnu.org/PR42509 -- does that help?
>
> Ciao!
> Steven
