search for: ltocodegeneration

On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: > Hi folks, > > I just committed a new backend for the Hexagon processor. After committing, I was able to successfully check out, build and test with the new changes. The x86_64 build on the buildbot is failing, however. Here's the build error: > > llvm[2]: Linking Debug+Asserts executable llvm-mc >

On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: > > On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: > >> Hi folks, >> >> I just committed a new backend for the Hexagon processor. After >> committing, I was able to successfully check out, build and test with >> the new changes. The x86_64 build on the buildbot is failing, >> however.

Hi folks, I just committed a new backend for the Hexagon processor. After committing, I was able to successfully check out, build and test with the new changes. The x86_64 build on the buildbot is failing, however. Here's the build error: llvm[2]: Linking Debug+Asserts executable llvm-mc /home/baldrick/osuosl/slave/llvm-x86_64/llvm/tools/llvm-mc/Debug+Asserts/llvm-mc.o: In function

On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: > > On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: > >> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>> >>> >>> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >>> >>>> Hi folks, >>>> >>>> I just committed a new backend for the Hexagon

On Dec 12, 2011, at 2:51 PM, Tony Linthicum wrote: > On 12/12/2011 4:49 PM, Eric Christopher wrote: >> >> >> On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: >> >>> >>> On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: >>> >>>> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>>>> >>>>>

On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: > On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >> >> >> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >> >>> Hi folks, >>> >>> I just committed a new backend for the Hexagon processor. After committing, I was able to successfully check out, build and test with the new changes.

On 12/12/2011 4:49 PM, Eric Christopher wrote: > > On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: > >> >> On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: >> >>> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>>> >>>> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >>>> >>>>> Hi folks,

I'm hitting this. Is there ETA for the fix? Evan On Dec 12, 2011, at 2:58 PM, Daniel Dunbar wrote: > > On Dec 12, 2011, at 2:51 PM, Tony Linthicum wrote: > >> On 12/12/2011 4:49 PM, Eric Christopher wrote: >>> >>> >>> On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: >>> >>>> >>>> On Dec 12, 2011, at 2:36

LTOCodeGenerator::addModule (which is wrapped by lto_codegen_add_module) takes an LTOModule as an argument and links the latter's llvm::Module into its own. It does not change the latter's llvm::Module. The lto_module_dispose API call destroys an LTOModule. This frees the LTOModule's llvm::Module, but also invalidates strings returned by, e.g., lto_module_get_symbol_name. I propose

Following on from my last question, based on such information as I've been able to find on Google, I get the impression llvm-link is effectively deprecated / not actively maintained, because the focus of whole-program optimization is now on the gold plugin. Is that the case, or am I missing something? Running searches over the source tree, it seems the Linker class that actually implements

Ah! Okay. A quick test of llvm-lto gets an error: llvm-lto: error adding file 'main.bc': Linking COMDATs named '??_7_Iostream_error_category at std@@6B@': invalid selection kinds! Would it be the case that llvm-lto is also deprecated in favor of the gold plugin? On Tue, Feb 10, 2015 at 4:47 PM, Teresa Johnson <tejohnson at google.com> wrote: > LTOCodeGenerator is used

> On Aug 9, 2016, at 9:24 AM, Kevin Choi via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -Wl,--plugin=LLVMgold.so,--plugin-opt=emit-llvm This is totally Gold specific. The fact that he mentions using LTOCodeGenerator makes me think that he does not use Gold. > > http://llvm.org/docs/CommandGuide/opt.html <http://llvm.org/docs/CommandGuide/opt.html> >

In LTOCodeGenerator.cpp there are some options related to optimization remarks. On MacOS, I can pass in this option to enable them: -Wl,-mllvm,-lto-pass-remarks-output=remarks But on Linux using 2.29.1 binutils version of gold, I try this alternative: -Wl,--plugin-opt,-lto-pass-remarks-output=remarks But I get this error message: LLVMgold: Unknown command line argument

I thought it was already fixed, so no. I hate to say this, but can you try first: touch $LLVM_SRC_ROOT/LLVMBuild.txt and a make? If that doesn't work, try a make clean? I'll try and find a real fix tomorrow. - Daniel On Dec 12, 2011, at 5:44 PM, Evan Cheng wrote: > I'm hitting this. Is there ETA for the fix? > > Evan > > On Dec 12, 2011, at 2:58 PM, Daniel

Hi Guys , We enabled the LTO on our code base and found that LTO uses the integrated/builtin assembler to emit the final optimized code .O (FileType= CGFT_ObjectFile) . Can we bypass this semantic ,for something like you emit .S file (FileType=CGFT_AssemblyFile), Then we pass this .S file to our native assembler and the linker .....any switch/ options do so ? i.e something like as we have

Hi All, In LTO, we load in the source modules and link the source modules into a destination module. Lots of MDNodes are only used by the source modules, for example Xalan used 649MB for MDNodes after loading and linking, but the actual destination module only has 393MB of MDNodes. There are 649-393MB (40% of 649MB) not used. MDNodes belong to the Context, deleting modules will not release the

On 9/22/11 4:04 PM, Jinwook Shin wrote: > Thanks John. I appreciate your help. De nada. > > I have taken the libLTO approach and it worked like a charm :) For > those who wanted to achieve the same thing, below are the steps I've > taken. > > John -- a small question: I thought I wouldn't need to touch > Makefiles at all, but that wasn't the case. Could

Thanks John. I appreciate your help. I have taken the libLTO approach and it worked like a charm :) For those who wanted to achieve the same thing, below are the steps I've taken. John -- a small question: I thought I wouldn't need to touch Makefiles at all, but that wasn't the case. Could you take a look at Step 4) and tell me what you think? Thanks! 1) Create your own libLTO and

On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren at gmail.com> wrote: > Hi All, > > In LTO, we load in the source modules and link the source modules into a > destination module. > Lots of MDNodes are only used by the source modules, for example Xalan > used 649MB for MDNodes after loading and linking, but the actual > destination module only has 393MB of

On Tue, Nov 12, 2013 at 4:38 PM, Chandler Carruth <chandlerc at google.com>wrote: > > On Tue, Nov 12, 2013 at 4:29 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> Hi All, >> >> In LTO, we load in the source modules and link the source modules into a >> destination module. >> Lots of MDNodes are only used by the source modules, for example