This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH,RFC] CSE path following on basic blocks

On 11/28/06, Eric Botcazou <> 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 ;-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]