Attached is the start of a patch to make the gold plugin work on Darwin for use as a cross-compiler. 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. 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? deep -------------- next part -------------- A non-text attachment was scrubbed... Name: gold-plugin-darwin-cross.diff Type: application/octet-stream Size: 446 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091005/1f60368e/attachment.obj>
2009/10/4 Sandeep Patel <deeppatel1987 at gmail.com>:> Attached is the start of a patch to make the gold plugin work on > Darwin for use as a cross-compiler.Nice. I checked that it still builds correctly on linux. I think it is fine, but Nick should probably have a look.> 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.> 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?> deep >Thanks, -- Rafael Ávila de Espíndola
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
Sandeep Patel wrote:> Attached is the start of a patch to make the gold plugin work on > Darwin for use as a cross-compiler. 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.With this patch, it seems that it produces a file named LLVMgold.so instead of libLLVMgold.so. Any ideas? I'll look into it later if you're not sure why, but that's the only thing blocking committing it.> 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?That's not all. -disable-fp-elim will be dropped, for example. The libLTO generated code assumes -mcpu=native, -march=native, frame pointers eliminated, etc. This should all be flag controlled but nobody's bothered to do it yet. Nick
On Fri, Oct 9, 2009 at 6:15 AM, Nick Lewycky <nicholas at mxc.ca> wrote:> Sandeep Patel wrote: >> >> Attached is the start of a patch to make the gold plugin work on >> Darwin for use as a cross-compiler. 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. > > With this patch, it seems that it produces a file named LLVMgold.so instead > of libLLVMgold.so. Any ideas?LOADABLE_MODULE causes that, but it is necessary to get -module passed to libtool.> I'll look into it later if you're not sure why, but that's the only thing > blocking committing it. > >> 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? > > That's not all. -disable-fp-elim will be dropped, for example. The libLTO > generated code assumes -mcpu=native, -march=native, frame pointers > eliminated, etc. This should all be flag controlled but nobody's bothered to > do it yet.How does this work in the Darwin linker? Or doesn't it? deep