similar to: [LLVMdev] SUBJ: Passing arguments to the LTO

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

Hi, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting

Hi all, Please check out our recent ISCA publication that introduces a new performance profiling technique for analyzing parallel programs along with an open source tool to collect the profiles. The tool is written into LLVM's LTO. Could someone please add the paper to http://llvm.org/pubs/ ? Here is the citation: Harmony: Collection and Analysis of Parallel Block

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

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

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

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

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

On Tue, Nov 12, 2013 at 4:46 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > 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

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

Two suggestions: - Use a 64-bit operating system. - You could disable the LTO optimizations by commenting out a few lines in tools/lto/LTOCodeGenerator.cpp to determine if the problem is a pass or with LTO itself. On Wed, Oct 17, 2012 at 10:38 AM, Sahoo, Swarup Kumar <ssahoo2 at illinois.edu> wrote: > Hi, > > I was trying to build clang (svn head version) using clang-3.1

Is there an easy way to remove data frame columns by name instead of by index? The following gives the idea remove<-c("subj","drug") data[-remove] I found a solution with a few evals and substitutes, similar to that used in reshapeLong, but there must be an easier way out. Dieter --------------------------------------- Dr. Dieter Menne Biomed Software 72074 T?bingen Tel

On Tue, Nov 12, 2013 at 4:59 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Nov 12, 2013 at 4:46 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> 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

On Tue, Sep 15, 2015 at 3:31 PM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On 2015-Sep-02, at 19:31, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: >>> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < >>> dexonsmith at

----------------------------------------------------------------------- Martin T soovib m?ningaid Google'i uusi lahedaid tooteid kasutades t?husamalt suhelda. Kui teil on juba Gmail v?i Google Talk, k?lastage: http://mail.google.com/mail/b-b1582f7c47-bb95c4c048-xaFhqyy53hFz38AqKrnAp3IUOaM Kasutajaga Martin T vestlemiseks peate kl?psama seda linki. Selleks, et hankida endale Gmail ? rohkem

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

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,

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