This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] LTO plugin for coff, part 1: break out ELF-specific code and enable COFF builds
On Sat, Oct 02, 2010 at 06:05:02PM +0100, Dave Korn wrote:
> On 02/10/2010 17:13, Jack Howarth wrote:
> > On Sat, Oct 02, 2010 at 06:00:36PM +0200, Ralf Wildenhues wrote:
> >> Hi Dave,
>
> Hello Ralf and Jack,
>
> >> * Dave Korn wrote on Sat, Oct 02, 2010 at 06:10:21PM CEST:
> >>> This patch separates out the ELF-specific code from the LTO plugin into a
> >>> separate source file, and adds autoconfigury to select that or a COFF-specific
> >>> source file at build time. It also adds a configure-time option,
> >>> --enable-lto-plugin, which forcibly overrides the default decision about
> >>> whether or not to build the LTO plugin.
>
> >> Please explain why the existing --enable-lto switch is not sufficient.
>
> I thought it was best not to include experimental features under it. I
> guess it wouldn't do any harm to build the plugin unconditionally when LTO is
> enabled, even though it's useless for now, but looking at the existing code:
>
> > # If LTO is enabled, add the LTO front end.
> > extra_host_libiberty_configure_flags=
> > if test "$enable_lto" = "yes" ; then
> > case ,${enable_languages}, in
> > *,lto,*) ;;
> > *) enable_languages="${enable_languages},lto" ;;
> > esac
> > if test "${ENABLE_GOLD}" = "yes" ; then
> > configdirs="$configdirs lto-plugin"
> > extra_host_libiberty_configure_flags=--enable-shared
> > fi
> > fi
>
> ... AFAIK we don't have any easy way of saying "If ENABLE_GOLD *or* target
> format is COFF" available in the top-level configure file, and I didn't want
> to just remove the ENABLE_GOLD test and unconditionally build the plugin
> whenever LTO is enabled, because that could affect any number of other
> platforms I don't know about.
>
> >> The configure user API for LTO starts to look quite complex and
> >> unorganized, with --enable-lto, --enable-lto-plugin, and
> >> --enable-languages=lto. Put another way, the poor user shouldn't have
> >> to bother with the details, and will want LTO by default whenever
> >> possible.
>
> Yeah, I see what you mean. Well, it's all been experimental status so far,
> which is why none of it was on by default. Also, it looks to me like
> --enable-languages=lto isn't the user's problem, since --enable-lto implies it
> unconditionally. So there's only one top-level option relevant to users right
> now, and I'm proposing to add one more. I wouldn't be adverse - once it's all
> working - to being asked to send a final patch that removes this option again
> (or perhaps defaults it based on --enable-lto, so that the negative form is
> still available as --disable-lto-plugin as a get-out-of-jail-free-card.
>
> > A good first step would be for the COFF targets to enable lto by default
> > for their existing lto infrastructure (as darwin has for Mach-O lto support).
> > This would greatly simplify lto for COFF end-users.
>
> I'm not sure lto is ready for COFF end-users until we've got the linker
> plugin working. Won't switching it on prematurely just give us a massive
> support headache having to explain to our users that yes, it's not supposed to
> do anything much yet?
>
> I am fully intending to have all this resolved in the released gcc-4.6, but
> we're not even at the end of stage1 yet, and I wanted to get this chunk of
> refactoring in before then, so that the remaining stuff becomes low enough
> risk that it doesn't matter if it spills into stage 3 a bit.
Dave,
The current experience on darwin is that we are more likely to suffer regressions
related to lto patches whether or not lto is defaulted on. In particular, I am thinking
of PR44240 and PR45730 which are caused by changes for improved lto support which
manifest themselves regardless of whether lto is enabled.
Jack
>
> cheers,
> DaveK