On Mon, Oct 5, 2009 at 8:04 PM, Rafael Espindola <espindola at google.com> wrote:>> I have no idea how to reduce this. >> >> Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8 >> --with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the >> bitcode will be "armv7-eabi" but the actual CPU subtarget won't be >> known to the gold plugin. I'd think the same would be true for any >> cross-compiler. Note that self-hosting X86 will eventually use a CPUID >> instruction to determine the proper subtarget on the fly so it will >> usually be correct. > > I will try to take a look, but it will take some time.If we can decide the way we want the options passed, I can take a stab at it (or more likely Viktor will). I'd expect that gold will need an option that tells it that some following option or options are to be passed to the plugin. The plugin API will need to pass these flags down. Any suggestions here that would be compatible with the FSF view of the universe would be welcome. I assume the plugin's options should be either the existing cl::opt ones (-mcpu, etc.) or similar to the llc ones. deep
> If we can decide the way we want the options passed, I can take a stab > at it (or more likely Viktor will).The linker has a -plugin-opt option. You probably do something like -fplugin-opt=-mcpu> I'd expect that gold will need an option that tells it that some > following option or options are to be passed to the plugin. The plugin > API will need to pass these flags down. Any suggestions here that > would be compatible with the FSF view of the universe would be > welcome.On the gcc plugin we just reexec gcc, so the plugin options are gcc options. Not sure if there is much to be gained here since the two plugins are independent.> I assume the plugin's options should be either the existing cl::opt > ones (-mcpu, etc.) or similar to the llc ones.You are free to name it, but using something similar to a llc option is probably a good idea.> deep >Cheers, -- Rafael Ávila de Espíndola
> I'd expect that gold will need an option that tells it that some > following option or options are to be passed to the plugin. The plugin > API will need to pass these flags down.This is already in place. Linker command line options could look like -plugin pathname [ -plugin-opt arg1 ] [ -plugin-opt arg2 ] ... gold will load plug-in by pathname and pass to it the arguments arg1, arg2, etc. in the same order in which they appear on the command line. -Viktor ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sandeep Patel [deeppatel1987 at gmail.com] Sent: Monday, October 05, 2009 1:21 PM To: Rafael Espindola Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] getting gold plugin to work? On Mon, Oct 5, 2009 at 8:04 PM, Rafael Espindola <espindola at google.com> wrote:>> I have no idea how to reduce this. >> >> Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8 >> --with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the >> bitcode will be "armv7-eabi" but the actual CPU subtarget won't be >> known to the gold plugin. I'd think the same would be true for any >> cross-compiler. Note that self-hosting X86 will eventually use a CPUID >> instruction to determine the proper subtarget on the fly so it will >> usually be correct. > > I will try to take a look, but it will take some time.If we can decide the way we want the options passed, I can take a stab at it (or more likely Viktor will). I'd expect that gold will need an option that tells it that some following option or options are to be passed to the plugin. The plugin API will need to pass these flags down. Any suggestions here that would be compatible with the FSF view of the universe would be welcome. I assume the plugin's options should be either the existing cl::opt ones (-mcpu, etc.) or similar to the llc ones. deep _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Mon, Oct 5, 2009 at 9:09 PM, Rafael Espindola <espindola at google.com> wrote:>> If we can decide the way we want the options passed, I can take a stab >> at it (or more likely Viktor will). > > The linker has a -plugin-opt option. You probably do something like > > -fplugin-opt=-mcpu>...>> I assume the plugin's options should be either the existing cl::opt >> ones (-mcpu, etc.) or similar to the llc ones. > > You are free to name it, but using something similar to a llc option > is probably a good idea.LINK_COMMAND_SPEC in gcc.c will need to change to add: %{O*:-plugin-opt=-O%*} \ %{w:-plugin-opt=-w} \ %{f*:-plugin-opt=-f%*} \ ${m*:-plugin-opt=-m%*} \ and then the plugin will need to have an argument translation process similar to llvm-gcc's LLVM_SET_TARGET_OPTIONS, LLVM_SET_MACHINE_OPTIONS, and LLVM_SET_SUBTARGET_FEATURES as well as all the logic in llvm-backend.cpp for translating options. I don't see any way to unify this logic with the llvm-gcc logic because llvm-gcc's decisions are derived from global state instead of a direct argument translation process. Yuck. Opinions welcome. deep
Rafael Espindola wrote:>> If we can decide the way we want the options passed, I can take a stab >> at it (or more likely Viktor will). > > The linker has a -plugin-opt option. You probably do something like > > -fplugin-opt=-mcpuThe gold plugin has its own option list, it doesn't pass options through to LLVM -- which come to think of it would probably be a really good idea. Adding a call to "cl::ParseCommandLineOptions" for the unknown options would be a good change to have. Nick>> I'd expect that gold will need an option that tells it that some >> following option or options are to be passed to the plugin. The plugin >> API will need to pass these flags down. Any suggestions here that >> would be compatible with the FSF view of the universe would be >> welcome. > > On the gcc plugin we just reexec gcc, so the plugin options are gcc > options. Not sure if there is much to be gained here since the two > plugins are independent. > >> I assume the plugin's options should be either the existing cl::opt >> ones (-mcpu, etc.) or similar to the llc ones. > > You are free to name it, but using something similar to a llc option > is probably a good idea. > >> deep >> > > > Cheers,