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]
Other format: [Raw text]

Why does flow_loops_find modify the CFG, again?


Hi Zdenek, all,

I'm running into some troubles with an if-conversion pass that runs
after reload, where we have to avoid lifting insns across a loop
exit edge into a loop.  ifcvt.c uses flow_loops_find to find loops
and mark all loop exit edges:

  if ((! targetm.cannot_modify_jumps_p ())
      && (!flag_reorder_blocks_and_partition || !no_new_pseudos
          || !targetm.have_named_sections))
    {
      struct loops loops;

      flow_loops_find (&loops);
      mark_loop_exit_edges (&loops);
      flow_loops_free (&loops);
      free_dominance_info (CDI_DOMINATORS);
    }

I was wondering why we would sometimes *not* mark exit edges, but then
I remembered that for some reason flow_loops_find modifies the CFG,
which may lead to problems that we have to work around here.

But if we do not mark loop exit edges, we can sometimes end up doing
unprofitable if-conversions!

It seems to me that a function called "flow_loops_find" is supposed to
do *just* analysis, and not transformations.  Apparently it now first
transforms all loops into some canonical form, but that is completely
inappropriate and unnecessary for some users of this loops analysis.

Is this something that could be easily fixed?  E.g. can we make it
that flow_loops_find only performs transformations if asked to (by
adding a function argument for that)?

Gr.
Steven


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