On Mon, Oct 5, 2009 at 2:21 PM, Rafael Espindola <espindola at google.com> wrote:> 2009/10/4 Sandeep Patel <deeppatel1987 at gmail.com>: >> There needs to be a build step >> somewhere in llvm-gcc that copies it into libexec/<gcc >> poop>/libLLVMgold.so, but I've been doing that manually for now. > > Yes, this is bad. The problem is that we build the plugin in llvm, not > llvm-gcc. Another option is to add a new search directory to llvm-gcc. > That way you could configure llvm-gcc with a --gold-plugin-dir=<path> > and the resulting binary would search there. This would work nicely > when using an already installed llvm copy.That would work for gold, but what about nm, etc.?>> It doesn't seem that simple use of -O4 results in the plugin learning >> what subtarget is desired. I presume that the llvm-gcc driver needs to >> pass -mcpu down through collect2 into ld somehow. Has anybody solved >> this already? Perhaps we should finally just put the feature string >> into the bitcode? > > Interesting. It is probably better to pass it via the command line. I > will try to take a look at it. Do you have a small testcase?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. deep
> That would work for gold, but what about nm, etc.?You would still need to copy it :-(> 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.> deep >Cheers, -- Rafael Ávila de Espíndola
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