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] Make CSE path following use the CFG


On 12/11/06, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:
> * Without -fcse-follow-jumps, CSE is now purely a local pass.  It
>   is easy to revert this to the current behavior, but the change
>   is deliberate: It gives a rather nice speedup at -O1, and most
>   of the things that CSE does are local anyway so the effect on
>   the generated code is not that large.

You still invoke cse_find_path when flag_cse_follow_jumps is false, which
is a sheer waste of time.  Moreover, AFAICS you didn't document the change.

A "sheer waste of time" is one of the greatest exaggerations I've seen in a while. If you're looking for real "sheer waste of time" issues, fix the half dozen quadratic bottlenecks we still have in cse.c, or if you don't like working on cse.c, take on combine.c, the scheduler, VRP, or regclass.

It's just a function call, you know.

You're right about the documentation change. I will fix that.


>       (cse_main): Rewrite.  Look for extended basic block headers
>       and call cse_extended_basic_block on them until all paths that
>       start at this header are exhausted.

          /* Get a reasonable extimate for the maximum number of qty's
             needed for this path.  For this, we take the number of sets
             and multiply that by MAX_RECOG_OPERANDS.  */
          max_qty = ebb_data.nsets * MAX_RECOG_OPERANDS;

You have replaced the 15-year-old trick with yours so you should explain
the heuristics, the second sentence above being by no means such an
explanation.

I had a longer comment and I was asked to remove that.


>       (rest_of_handle_cse): Verify that the CFG is incrementally updated
>       and correct after cse_main.

You merged some left-overs at the beginning of the function.

Yes, it seems I forgot to remove the debug counter I added to find out what went wrong with the new Java failure I had. I'll remove that too, sorry for this sloppiness.

This apparently broke Ada on i586:

/home/eric/build/gcc/native32/./gcc/xgcc
-B/home/eric/build/gcc/native32/./gcc/-B/home/eric/install/gcc/i586-suse-linux/bin/
-B/home/eric/install/gcc/i586-suse-linux/lib/
-isystem /home/eric/install/gcc/i586-suse-linux/include
-isystem /home/eric/install/gcc/i586-suse-linux/sys-include -c -g -O2 -fPIC
-W -Wall -gnatpg  a-nlcefu.ads -o a-nlcefu.o
+===========================GNAT BUG DETECTED==============================+
| 4.3.0 20061211 (experimental) (i586-suse-linux-gnu) GCC error:           |
| in rest_of_handle_cse, at cse.c:6975                                     |
| Error detected at a-ngcefu.adb:710:1 [a-nlcefu.ads:19:1]                 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
+==========================================================================

I'll try to find out why.

Yikes! I even tested Ada with a previous version of the patch. Grrrrrrr....


My guess is that it's another behind-the-back change of a may-trap
insn into a non-trapping insn.  You can use the debug counter to find
out at which cse_main invocation the problem appears, and then go
through the changes to all BB_END insns (or move the counter inside
cse_insn).

Gr.
Steven


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