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: [lto] remove rebuild_ssa_for_lto


On 12/3/07, Nathan Froyd <froydnj@codesourcery.com> wrote:
> This patch forges ahead with the plan I suggested Friday to remove the
> current full rebuilding of SSA we do.  The only changes from the patch
> posted Friday are removing the early_lto_passes from the pass manager
> along with the deletion of their associated code and finding yet another
> tree flag that we need to serialize.
>
> The remaining failures fall into the following non-exhaustive
> categorization:
>
> - Not supporting nested functions;
> - Not supporting flexible arrays;
> - Not supporting weird user-defined types (complex char);
> - Problems with aliasing (maybe? -- 20020619-1.c);
> - Problems with bitfields (e.g. 20040629-1.c);
>
> Stats from just the -O2 -flto tests from execute.exp look like:
>
>                 === gcc Summary ===
>
> # of expected passes            1838
> # of unexpected failures        51
> # of unresolved testcases       31
>
> As for SPECint2000, we can compile and run 181.mcf, 186.crafty,
> 197.parser, and 256.bzip2.  164.gzip and 175.vpr compile, but fail for
> reasons I have not yet investigated.  As for the remaining C benchmarks:
>
> - 176.gcc asserts in dwarf2out.c;
> - 253.perlbmk apparently redeclares things incompatibly;
> - 254.gap does the same;
> - 255.vortex dies with corrupt LTO information;
> - 300.twolf has mismatching declarations somewhere.
>
> So we're doing better.
>
> Committed to the LTO branch.
>
> -Nathan
>
> gcc/
>         * tree-into-ssa.c (rebuild_ssa_for_lto): Remove.
>         (pass_rebuild_ssa_for_lto): Remove.
>         * tree-optimize.c (gate_early_lto_passes): Remove.
>         (pass_early_lto_passes): Remove.
>         * passes.c (init_optimization_passes): Remove pass_early_lto_passes
>         and its sub-passes.
>         * tree-pass.h (pass_early_lto_passes, pass_rebuild_ssa_for_lto):
>         Remove.
>         * lto-tree-flags.def (VAR_DECL): Add volatile_flag.
>
> gcc/lto/
>         * lto.c (lto_read_variable_formal_parameter_constant_DIE): Set
>         TREE_THIS_VOLATILE if the associated type is a volatile type.
>         (lto_materialize_function): Remove call to init_ssa_operands.
>         * lto-read.c (input_expr_operand): Add SSA_NAME_VAR as a referenced
>         variable when reading an SSA_NAME.  Do the same when reading a
>         RESULT_DECL, a RETURN_EXPR, or an MTAG.

This is, well, not right.
1. You should be running pass_referenced_vars, which will find all the
referenced vars for you and add them. If it doesn't, it is buggy, and
should be fixed.

This will probably not add MTAGS, because MTAG's get added to
referenced vars by compute_may_aliases.

Only may_alias creates MTAG's, you shouldn't be serializing them.  I
can't even see how you have them at the point you are serializing (my
guess is one of your early opts is per-function creating them

> +      /* Fill in properties we know hold for the rebuilt CFG.  */
> +      cfun->curr_properties = PROP_ssa | PROP_alias;

You can't have PROP_alias unless you have rebuild NMT's, SMT's, mtags,
partitioning info, addresses_taken, call_clobbering, SFT's, etc.

Some of these are not stored on a per-function basis, which is why you
can't have aliasing on IPA form right now (among other reasons), so
you can't serialize them at the point you are anyway, because they
don't exist for all functions at once.  It's certainly very wrong to
claim PROP_alias to be set.

The passes LTO calls when it is done reading in should include
pass_referenced_vars and have a TODO_may_alias on one of them (The
first that normally does this is pass_create_structure_vars).


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