This is the mail archive of the
mailing list for the GCC project.
Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 01 Jun 2009 13:35:09 -0400
- Subject: Re: [trunk<-vta] Re: [vtab] Permit coalescing of user variables
- References: <firstname.lastname@example.org> <4702B1C0.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Ian Lance Taylor wrote:
Alexandre Oliva <firstname.lastname@example.org> writes:I don't think we need the options. Is there a reason we can't leave the
current default behaviour the way it is, and have the VTA code simple
enable the "best" choices for it. (which I think means coalesce
+Permit the copyrename pass to subject inlined variables to coalescing
+into other variables. This may harm debug information of such inlined
+variables, but it will keep variables of the main function apart from
+each other, such that they are more likely to contain the expected
+values in a debugging session. This option is enabled by default.
+Permit the copyrename pass to subject all variables to SSA coalescing.
+This may severely limit the ability to debug a program. In the negated
+form, this flag prevents SSA coalescing of user variables, including
If we are going to have these options, the documentation needs to be
better. You have written it from the compiler implementor's point of
view. You need to rewrite the docs from the user's point of view: what
are the user visible effects of these options?
Also the option names are from the implementor's point of view rather
than the user's point of view. No ordinary user will ever use an option
named -ftree-coaelesce-inlined-vars, which raises the question of
whether we need the option at all.