[PATCH] Fix make_rename_temp to work at -O0

[PATCH] Fix make_rename_temp to work at -O0

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 165 bytes --]

This is needed so that tree-complex (and the analogous vector lowering 
pass that I am going to submit soon) can work at -O0 too, when SSA is 
not available.

Paolo

[-- Attachment #2: gcc-tree-ssa-adapt-complex-lowering-for-no-ssa.patch --]
[-- Type: text/plain, Size: 740 bytes --]

2004-07-13  Paolo Bonzini  <bonzini@gnu.org>

	* tree-dfa.c (make_rename_temp): Work even if not
	in SSA form.

Index: gcc/tree-dfa.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-dfa.c,v
retrieving revision 2.11
diff -u -r2.11 tree-dfa.c
--- gcc/tree-dfa.c	18 Jun 2004 14:05:19 -0000	2.11
+++ gcc/tree-dfa.c	21 Jun 2004 14:31:16 -0000
@@ -492,8 +492,11 @@
 make_rename_temp (tree type, const char *prefix)
 {
   tree t = create_tmp_var (type, prefix);
-  add_referenced_tmp_var (t);
-  bitmap_set_bit (vars_to_rename, var_ann (t)->uid);
+  if (vars_to_rename)
+    {
+      add_referenced_tmp_var (t);
+      bitmap_set_bit (vars_to_rename, var_ann (t)->uid);
+    }
   return t;
 }
 

Re: [PATCH] Fix make_rename_temp to work at -O0

[Richard Henderson]

On Tue, Jul 13, 2004 at 01:01:44PM +0200, Paolo Bonzini wrote:
> 	* tree-dfa.c (make_rename_temp): Work even if not in SSA form.

Ok.


r~

Re: [PATCH] Fix make_rename_temp to work at -O0

[Richard Henderson]

On Tue, Jul 13, 2004 at 01:01:44PM +0200, Paolo Bonzini wrote:
> 	* tree-dfa.c (make_rename_temp): Work even if not
> 	in SSA form.

Actually, if you're going to move the tree-complex bits,
why not change them to use just create_tmp_var in the first place?



r~

Re: [PATCH] Fix make_rename_temp to work at -O0

[Paolo Bonzini]

> Actually, if you're going to move the tree-complex bits,
> why not change them to use just create_tmp_var in the first place?

Because my plan is to have complex and vector lowering happen at 
different times depending on whether optimization is active.

At -O0, they would happen last, just before expanding; they would happen 
together to save a bit of compilation time.  At higher optimization 
level, however, complex lowering would stay where it is now, after DCE 
and before DOM/loop passes; while vector lowering needs to go at least 
after the vectorizer.

Moving complex before CFG and SSA construction makes sense. 
Unfortunately, this is not true for the other users of make_rename_temp, 
such as phiopt and the vector lowering pass.  This patch to 
make_rename_temp is just preparatory work to make the gimplify_buildN 
patch work whether SSA is used or not.

That's because complex arithmetic could be subject to vectorization 
(though it is not right now).

Re: [PATCH] Fix make_rename_temp to work at -O0

[Richard Henderson]

On Wed, Jul 14, 2004 at 08:50:31AM +0200, Paolo Bonzini wrote:
> Because my plan is to have complex and vector lowering happen at 
> different times depending on whether optimization is active.

I don't see that that's an advantage.

> At -O0, they would happen last, just before expanding; they would happen 
> together to save a bit of compilation time.  At higher optimization 
> level, however, complex lowering would stay where it is now, after DCE 
> and before DOM/loop passes; while vector lowering needs to go at least 
> after the vectorizer.

Both need to happen before loop opts.  The vectorizer doesn't 
enter into it -- we shouldn't be lowering vector types supported
by the hardware, and the vectorizer shouldn't be creating any
that aren't supported by the hardware.




r~

Re: [PATCH] Fix make_rename_temp to work at -O0

[Paolo Bonzini]

> Both need to happen before loop opts.  The vectorizer doesn't 
> enter into it -- we shouldn't be lowering vector types supported
> by the hardware, and the vectorizer shouldn't be creating any
> that aren't supported by the hardware.

But the vectorizer can convert

    char *p;
    for (i = 0; i < 32; i++)
      p[i] |= q[i];

to work 32-bit or 64-bit at a time if suitable alignment can be guaranteed.

Paolo

Re: [PATCH] Fix make_rename_temp to work at -O0

[Diego Novillo]

On Wed, 2004-07-14 at 02:50, Paolo Bonzini wrote:
> > Actually, if you're going to move the tree-complex bits,
> > why not change them to use just create_tmp_var in the first place?
> 
> Because my plan is to have complex and vector lowering happen at 
> different times depending on whether optimization is active.
> 
> At -O0, they would happen last, just before expanding; they would happen 
> together to save a bit of compilation time.  At higher optimization 
> level, however, complex lowering would stay where it is now, after DCE 
> and before DOM/loop passes; while vector lowering needs to go at least 
> after the vectorizer.
> 
I am moving complex lowering much earlier in the pipeline.  Right after
we go into SSA, so that more scalar code is exposed to the early scalar
passes.

I'd do it earlier, but right now it assumes that we are in SSA form. 
This doesn't really make much sense to me, but I haven't really looked
into complex lowering.


Diego.

Re: [PATCH] Fix make_rename_temp to work at -O0

[Paolo Bonzini]

> I'd do it earlier, but right now it assumes that we are in SSA form. 

That's because of make_rename_temp.  Try now.

The patch that Richard Henderson approved and I have applied (with a 
trivial correction* due to changes in tree_rest_of_compilation made 
since when I had developed the patch), allows it to work much earlier 
and even at -O0, just after the CFG is built.

Paolo

* Here is it:

@@ -501,7 +501,7 @@
  make_rename_temp (tree type, const char *prefix)
  {
    tree t = create_tmp_var (type, prefix);
-  if (vars_to_rename)
+  if (referenced_vars)
      {
        add_referenced_tmp_var (t);
        bitmap_set_bit (vars_to_rename, var_ann (t)->uid);

Re: [PATCH] Fix make_rename_temp to work at -O0

[Richard Henderson]

On Wed, Jul 14, 2004 at 09:30:39AM -0400, Diego Novillo wrote:
> I'd do it earlier, but right now it assumes that we are in SSA form. 

Only in how temps are created.  See earlier in this argument.

I personally think it makes most sense to do this lowering 
before the cfg since (1) we don't care about blocks, and 
iterating over a single unified stmt list is easy and (2)
we create new blocks, which we then have to play games to
update the cfg.


r~