This is the mail archive of the gcc-patches@gcc.gnu.org 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: New Optimization: Partitioning hot & cold basic blocks


On Wed, Jan 28, 2004 at 04:23:05PM -0800, Caroline Tice wrote:
> I am sorry for my ignorance, but I don't quite understand what aspect of
> my optimization you are stating "most targets don't support".   I 
> *thought* you meant they didn't support long conditional branches,
> when I thought meant I needed to have code to convert conditional
> branches into unconditional branches in most cases where a conditional
> branch may attempt to cross between sections.  Which I do.

Most targets don't support long unconditional branches either.
They have to be implemented by indirect branches.

> I know it does not work correctly with C++ or exception handling in 
> general. I attempted to make sure that my optimization was not called
> in that case,  adding the "!flag_exceptions" to the condition for
> calling my code, in toplev.c:

I missed this in my first reading of the code.  Yes, this works.
It would be slightly nicer to warn about the option mismatch, since
this can be detected quite early.

It would be much nicer to actually Do The Right Thing and emit EH
info that works properly across section boundaries though.  This
shouldn't be *that* hard to do.

A dwarf2 FDE can only cover a contiguous address region.  But all
you need for the .text.cold region is to create a new FDE and emit
copies of the frame state at the beginning of the region.  This 
might be helped by some unreviewed code Zdenek has done to build
the unwind information on a per-block basis.

> Okay, I was under the impression that correct debugging wasn't a 
> primary issue, but if you feel it is, I will see what I can do to
> address this.

What I mean is that you can't leave it unaddressed indefinitely.
You must commit to fixing it eventually.

All three of these problems are made vastly easier if you arrange
for there to be exactly one transition between sections.  That is,
all of the code for ".text" comes first, and all of the code for
".text.cold" comes next, and not switch back and forth repeatedly.
I havn't examined your bb-reorder code to see if this is in fact
enforced.  Is it?

I think all of the ugliness you add to final.c wrt insn addreses
can be removed if you require that targets implement special patterns
to explicitly transition between sections.  Thus we don't have to
come up with arbitrarily large numbers to satisfy the pc-dest test
in normal branch patterns.


r~


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