This is the mail archive of the gcc@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]

representing noreturns and traps in the CFG


Hi,
I was taking a look at replacing the optimizations dealing with traps in jump.c
by if converison pass.  But it looks like these three simplifiers are just
special case of jump forwarding and threading, so I would love to comonize the
code in optimize_cfg.

With the return instructions, I plan to do same optimization, so I can simply
forward any branch to "EXIT_BLOCK_PTR" and redirect_edge_and_branch will take
care to emit proper (conditional) return instruction using exactly same logic
as it does have currently for jumps.

If we had "TRAP_BLOCK_PTR", I can do the same for traps.  Thinking more about
it, the idea looks quite good to me. Similary we can have "NORETURN_BLOCK_PTR"
for noreturn calls and we will get for free the crossjumping and other
optimizations on these.

Drawback is that we will introduce more "not well behaved" blocks. Currently
numer of places in compiler are special casing these.  But IMO my giving
them negative indexes, make BASIC_BLOCK to grok them, we can generalize these
tests to any of these extra BBs.

Last one is that we do have different trap codes and we will thus need multiple
trap blocks generated at runtime.

But overall, does the idea of adding these extra blocks sound sane?
I believe that not only the cleanup_cfg would benefit from that, the
postdominance algorithm and few other places should get more regular too IMO.

Honza


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