[PATCH,RFC] CSE path following on basic blocks

[Steven Bosscher]

On 11/28/06, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> I agree that, in the cfglayout implementation, following one edge and not the
> other is kind of strange, so it would indeed make sense to turn f_c_f_j into
> the predicate for pure locality.  But the change should be clearly stated in
> the code and then cse_find_path not invoked if f_c_f_j if false.

Yes, that was a good point.  I'll make that change too.

> > Well, we know that prev == bb_head, and a basic block with a NULL
> > bb_head can't occur.  The rest is just what the code was before.
>
> Then the gcc_assert seems pretty useless there too.

No, actually it is a bug.  That code was supposed to look for the
previous insn, and I made it look for BB_HEAD.  So you've discovered a
real bug in that change. Thanks for that :-)

> > The old code does think it computes an upper bound, but if you remove
> > the 500 from CSE as it is on the trunk, it will also ICE, usually on
> > small functions (e.g. I had a test case with max_qty == 3, and we
> > allocated 6 qtys).  I don't know where the extra qty's come from yet.
>
> OK, thanks for the clarification.  The compiler doesn't really write past the
> end of qty_table, right?  I was somewhat confused by this assertion in your
> comment, because sanity checks are supposed to prevent that.

If max_qty is *not* set to 500 for small functions, and checking is
disabled, then cse *does* write past the end of qty_table.  This
showed up for me as memory corruption that glibc complains about.

With checking enabled, you'd trivver the assert in make_new_qty.

If max_qty = MAX(2*nsets,500) then we don't write past the end of qty_table.

> > No, I will not do this for the current patch (but I will look into it
> > later because I need to fix this anyway if I'm going to save/restore
> > the hash table at the end of each basic block).
>
> Then why multiply by MAX_RECOG_OPERANDS?  Why not just keep the almost 15-year
> old trick?

Because I don't understand why we would write past the end of
qty_table.  It leaves me with a feeling that, given the right test
case, we could even trigger that problem if we use the 15 year old
trick.

But maybe I'm being too conservative.  It's a known shortcoming in
most aerospace engineers ;-)

Gr.
Steven