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: PR tree-opt/19484: noreturn vs. function pointer propagation

Richard Sandiford wrote:

  (a) Forbid the replacement.  (Is there a predicate that already
      checks for things like this?  I.e. which examines the context
      of the replacement, not just the operands being replaced?)

  (b) Extend cleanup_control_flow() so that it removes dead code after
      non-returning CALL_EXPRs.  Probably not a contender because the
      function would then be O(#statements) rather than O(#blocks).

  (c) Like (b), but only do the extra work when at least one CALL_EXPR
      is known to be affected.  (What would be the best way to record this?
      Some sort of global flag set by modify_stmt?  A new basic block flag?)

  (d) Like (c), but actually record which CALL_EXPRs are affected.
      (Some sort of global list instead of a global flag?)

(e) Remove the dead code in some other pass.


(f) When building the flowgraph, consider indirect calls block terminators. It's probably the easiest approach, but it may have a negative impact on some codes with many indirect calls (see stmt_ends_bb_p).

Otherwise, I like (c). You'll need to modify tree-ssa-dom.c:cprop_operand and tree-ssa-ccp.c:replace_uses_in. When either of them replaces the address of a function, put a marker on the block for cleanup_control_flow to read.

	PR tree-optimization/19484
	* tree-cfg.c (remove_fallthru_edge): New function.
	(cleanup_control_flow): Remove fallthru edges from calls that are
	now known not to return.

You need to remove all edges out of this block, actually. The block may have had EH edges.

Other than that, the patch looks fine.


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