This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question re missed CSEing at tree level
- From: Jeffrey A Law <law at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 29 Jul 2004 08:57:48 -0600
- Subject: Re: Question re missed CSEing at tree level
- Organization: Red Hat, Inc
- References: <10407290223.AA06358@vlsi1.ultra.nyu.edu>
- Reply-to: law at redhat dot com
On Wed, 2004-07-28 at 20:23, Richard Kenner wrote:
> While looking at the miscompilation of back_end.adb, I noticed the following
> in the t56.tailc file, which makes it all the way out:
>
> <L1>:;
> saved_stack.134_91 = __builtin_stack_save ();
> save_argv.54_96 = save_argv;
> T.271_97 = FRAME.267.next_arg;
> next_arg.51_98 = (types__TintB)T.271_97;
> T.55_99 = (<unnamed type>)next_arg.51_98;
> argv_ptr_100 = (*save_argv.54_96)[T.55_99];
> save_argv.233_177 = save_argv;
> T.236_176 = (*save_argv.233_177)[T.55_99];
> T.240_320 = (*T.236_176)[1]{lb: 1 sz: 1};
> if (T.240_320 == 0) goto <L3>; else goto <L5>;
>
> The computations for argv_ptr_100 and t.240_320 are identical and the
> second dereference should have been suppressed.
>
> Does anybody have any idea why it wasn't?
Well, the key to CSEing those statements is to first CSE the
RHS of the assignments to save_argv.54_96 and save_argv.233_177.
Until those are CSE'd (and then copy propagated) you're not going
to be able to CSE the RHS of the assignments to argv_ptr_100
and T.240_320.
Jeff