This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH,RFC] CSE path following on basic blocks
On 11/28/06, Eric Botcazou <email@example.com> 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
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
But maybe I'm being too conservative. It's a known shortcoming in
most aerospace engineers ;-)