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: [tree-ssa] scalarization of complex values


On Thu, Jan 15, 2004 at 01:46:15AM -0800, Richard Henderson wrote:
> You did good work here.  I took the patch, cleaned up Diego's code
> around it, and came up with the following.  If it passes overnight
> testing (I expect it will), I'll commit it tommorrow.

There was one problem that showed up: execute/20020227-1.c

> *************** can_be_scalarized_p (tree var)
> *** 219,240 ****
>   	  return false;
>   	}
>   
> -       /* FIXME: We should handle COMPLEX_TYPEs.  Structures with
> - 	 __complex__ fields are tested in the libstdc++ testsuite:
> - 	 26_numerics/complex_inserters_extractors.cc.  */
> -       if (TREE_CODE (TREE_TYPE (field)) == COMPLEX_TYPE)
> - 	{
> - 	  if (tree_dump_file && (tree_dump_flags & TDF_DETAILS))
> - 	    {
> - 	      fprintf (tree_dump_file, "Cannot scalarize variable ");
> - 	      print_generic_expr (tree_dump_file, var, 0);
> - 	      fprintf (tree_dump_file, " because it contains a __complex__ field, ");
> - 	      print_generic_expr (tree_dump_file, field, 0);
> - 	      fprintf (tree_dump_file, "\n");
> - 	    }
> - 	  return false;
> - 	}
> - 

This fragment is the culprit.  The problem is the fact that SRA
doesn't handle nested aggregtes at all.  I've updated the 
commentary in that area to look like this


@@ -187,6 +265,8 @@ can_be_scalarized_p (tree var)
       if (TREE_CODE (field) != FIELD_DECL)
 	continue;
 
+      /* FIXME: We really should recurse down the type hierarchy and
+	 scalarize the fields at the leaves.  */
       if (AGGREGATE_TYPE_P (TREE_TYPE (field)))
 	{
 	  if (tree_dump_file && (tree_dump_flags & TDF_DETAILS))
@@ -201,34 +281,36 @@ can_be_scalarized_p (tree var)
 	  return false;
 	}
 
+      /* FIXME: Similarly.  Indeed, considering that we treat complex
+	 as an aggregate, this is exactly the same problem.
+	 Structures with __complex__ fields are tested in the libstdc++
+	 testsuite: 26_numerics/complex_inserters_extractors.cc.  */
+      if (TREE_CODE (TREE_TYPE (field)) == COMPLEX_TYPE)


Rearranging SRA such that it could handle nested aggregates would
be a large boon.



r~


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