[PATCH] Allow DCE of const or pure calls

[PATCH] Allow DCE of const or pure calls

[Jakub Jelinek]

Hi!

This has been discussed recently, but I've posted it together with other
hacks which weren't intended for 4.3.  So here is the patch again alone,
bootstrapped/regtested on x86_64-linux (and will regtest it on ia64-linux
tonight as well).

Ok for trunk?

2007-11-02  Jakub Jelinek  <jakub@redhat.com>

	* dce.c (deletable_insn_p): Make const or pure calls deletable.

--- gcc/dce.c.jj	2007-10-28 19:34:17.000000000 +0100
+++ gcc/dce.c	2007-11-02 18:36:14.000000000 +0100
@@ -99,7 +99,8 @@ deletable_insn_p (rtx insn, bool fast)
   rtx body, x;
   int i;
 
-  if (!NONJUMP_INSN_P (insn))
+  if (!NONJUMP_INSN_P (insn)
+      && (!CALL_P (insn) || !CONST_OR_PURE_CALL_P (insn)))
     return false;
 
   body = PATTERN (insn);

	Jakub

Re: [PATCH] Allow DCE of const or pure calls

[Eric Botcazou]

> 2007-11-02  Jakub Jelinek  <jakub@redhat.com>
>
> 	* dce.c (deletable_insn_p): Make const or pure calls deletable.

Note that flow.c didn't delete these calls (unless inside libcalls) so I'm not 
sure we want this for 4.3.

-- 
Eric Botcazou

Re: [PATCH] Allow DCE of const or pure calls

[Mark Mitchell]

Eric Botcazou wrote:
>> 2007-11-02  Jakub Jelinek  <jakub@redhat.com>
>>
>> 	* dce.c (deletable_insn_p): Make const or pure calls deletable.
> 
> Note that flow.c didn't delete these calls (unless inside libcalls) so I'm not 
> sure we want this for 4.3.

Do you mean that you think that this might be undesirable because it
would be a surprise to users?  Or because it's a new feature, and thus
not suitable for Stage 3?

I'm not sure I agree with either statement, not having thought about it
much, but before I say anything I'd like to make sure I understand your
point of view.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [PATCH] Allow DCE of const or pure calls

[Jakub Jelinek]

On Sun, Nov 04, 2007 at 04:11:11PM -0800, Mark Mitchell wrote:
> Eric Botcazou wrote:
> >> 2007-11-02  Jakub Jelinek  <jakub@redhat.com>
> >>
> >> 	* dce.c (deletable_insn_p): Make const or pure calls deletable.
> > 
> > Note that flow.c didn't delete these calls (unless inside libcalls) so I'm not 
> > sure we want this for 4.3.
> 
> Do you mean that you think that this might be undesirable because it
> would be a surprise to users?  Or because it's a new feature, and thus
> not suitable for Stage 3?

While the patch worked just fine during bootstrap/regtesting on
x86_64-linux, during later testing I found it caused a bootstrap failure
on ia64-linux (which I haven't had time to analyze yet).
Therefore I'm withdrawing that patch for now.  Most of the dead const/pure calls
should be hopefully DCEd already in tree passes and at least in 4.3
__tls_get_addr etc. is using libcall blocks which are now DCEable again
even without this patch.

	Jakub

Re: [PATCH] Allow DCE of const or pure calls

[Andrew Pinski]

On 11/4/07, Jakub Jelinek <jakub@redhat.com> wrote:
> On Sun, Nov 04, 2007 at 04:11:11PM -0800, Mark Mitchell wrote:
> > Eric Botcazou wrote:
> > >> 2007-11-02  Jakub Jelinek  <jakub@redhat.com>
> > >>
> > >>    * dce.c (deletable_insn_p): Make const or pure calls deletable.
> > >
> > > Note that flow.c didn't delete these calls (unless inside libcalls) so I'm not
> > > sure we want this for 4.3.

At one point, we used to put pure/const functions in libcalls but we
don't after:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01198.html

So I think this is fixing a regression from 3.4 on a RTL level optimization.

-- Pnski

Re: [PATCH] Allow DCE of const or pure calls

[Eric Botcazou]

> Do you mean that you think that this might be undesirable because it
> would be a surprise to users?  Or because it's a new feature, and thus
> not suitable for Stage 3?

The latter.  And, as Jakub said, I don't think it would buy us much.

-- 
Eric Botcazou

Re: [PATCH] Allow DCE of const or pure calls

[Eric Botcazou]

> So I think this is fixing a regression from 3.4 on a RTL level
> optimization.

Note that, with this reasoning, every optimization that has been moved from 
RTL to Tree level is the source of a regression from 3.4.  But users cannot 
tell the difference between Tree level and RTL level optimizations, and DCE
of const or pure calls should already happen at the Tree level.

-- 
Eric Botcazou