This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH]: Fix PR tree-optimization/26260
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 14 Feb 2006 09:45:14 -0500
- Subject: [PATCH]: Fix PR tree-optimization/26260
It makes no sense to try to handle structures with thousands of fields
(many thousand in this case) field-sensitively, it just causes slowness.
Theoretically we *could* handle. Most of the slowness is actually in
creating the constraint variables for it (insert_field_into_fieldlist
and other linked list walkers), but IMHO, it's not worth it.
Bootstrapped and regtested on i686-pc-linux-gnu.
Applied to 4.1 branch and mainline.
--Dan
2006-02-14 Daniel Berlin <dberlin@dberlin.org>
Fix PR tree-optimization/26260
* doc/invoke.texi (max-fields-for-field-sensitive): Document
param.
* params.h (MAX_FIELDS_FOR_FIELD_SENSITIVE): New.
* params.def (PARAM_MAX_FIELDS_FOR_FIELD_SENSITIVE): Ditto.
* tree-ssa-structalias.c (create_variable_info_for): Use
MAX_FIELDS_FOR_FIELD_SENSITIVE.
Index: doc/invoke.texi
===================================================================
--- doc/invoke.texi (revision 110916)
+++ doc/invoke.texi (working copy)
@@ -6191,6 +6191,11 @@ protection when @option{-fstack-protecti
@item max-jump-thread-duplication-stmts
Maximum number of statements allowed in a block that needs to be
duplicated when threading jumps.
+
+@item max-fields-for-field-sensitive
+Maximum number of fields in a structure we will treat in
+a field sensitive manner during pointer analysis.
+
@end table
@end table
Index: params.h
===================================================================
--- params.h (revision 110916)
+++ params.h (working copy)
@@ -147,4 +147,6 @@ typedef enum compiler_param
PARAM_VALUE (PARAM_MIN_VIRTUAL_MAPPINGS)
#define VIRTUAL_MAPPINGS_TO_SYMS_RATIO \
PARAM_VALUE (PARAM_VIRTUAL_MAPPINGS_TO_SYMS_RATIO)
+#define MAX_FIELDS_FOR_FIELD_SENSITIVE \
+ ((size_t) PARAM_VALUE (PARAM_MAX_FIELDS_FOR_FIELD_SENSITIVE))
#endif /* ! GCC_PARAMS_H */
Index: tree-ssa-structalias.c
===================================================================
--- tree-ssa-structalias.c (revision 110916)
+++ tree-ssa-structalias.c (working copy)
@@ -3855,7 +3855,6 @@ check_for_overlaps (VEC (fieldoff_s,heap
}
return false;
}
-
/* Create a varinfo structure for NAME and DECL, and add it to VARMAP.
This will also create any varinfo structures necessary for fields
of DECL. */
@@ -3919,7 +3918,8 @@ create_variable_info_for (tree decl, con
if (use_field_sensitive
&& !notokay
&& !vi->is_unknown_size_var
- && var_can_have_subvars (decl))
+ && var_can_have_subvars (decl)
+ && VEC_length (fieldoff_s, fieldstack) <= MAX_FIELDS_FOR_FIELD_SENSITIVE)
{
unsigned int newindex = VEC_length (varinfo_t, varmap);
fieldoff_s *fo = NULL;
Index: params.def
===================================================================
--- params.def (revision 110916)
+++ params.def (working copy)
@@ -558,7 +558,15 @@ DEFPARAM (PARAM_MAX_JUMP_THREAD_DUPLICAT
"max-jump-thread-duplication-stmts",
"Maximum number of statements allowed in a block that needs to be duplicated when threading jumps",
15, 0, 0)
-
+
+/* This is the maximum number of fields a variable may have before the pointer analysis machinery
+ will stop trying to treat it in a field-sensitive manner.
+ There are programs out there with thousands of fields per structure, and handling them
+ field-sensitively is not worth the cost. */
+DEFPARAM (PARAM_MAX_FIELDS_FOR_FIELD_SENSITIVE,
+ "max-fields-for-field-sensitive",
+ "Maximum number of fields in a structure before pointer analysis treats the structure as a single variable",
+ 100, 0, 0)
/*
Local variables:
mode:c