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: [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


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