similar to: [LLVMdev] [RFC] LTO: deallocating llvm::Module inside lto_codegen_add_module

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

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

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

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

More stylistic nitpicking for consistency sakes... 1. __LTO__ -> LLVM_C_LTO 2. Do we need those #include's? 3. Rather than using underscore in function names, e.g. lt_foo_bar, use capital letters and also start with prefix LLVM. e.g. LLVMLTOFooBar. 4. lto_codegen_release -> lto_codegen_release_memory to be clearer and more consistent. 5. Use C comments /* ... */? 6. Please start

Hello. I work at Apple on our linker. We are working to improve support for llvm in our tools. A while back Devang created <llvm/LinkTimeOptimizer.h> a C++ interface which allows the linker to process llvm bitcode files along with native mach-o object files. For the next step we'd like our other tools like nm, ar, and lipo to be able to transparently process bitcode files

On Mon, Jun 1, 2015 at 6:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 29, 2015 at 6:15 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > > > On Fri, May 29, 2015 at 8:01 AM, Teresa Johnson <tejohnson at google.com> > > wrote: > >> > >> On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at

Hi, I am trying to get r114797 to build on Solaris 10u6 (5.10 Generic_142901-03). gcc 4.2 is installed and configured with: -bash-3.00$ /opt/gcc4/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ./configure --prefix=/opt/gcc4 --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++ Thread model:

> > >> I don't think that natively wrapped bitcode gets you as much as you think >> it does anyhow, unless you're duplicating a lot of information (ar, as >> discussed earlier, aside). I'm not too worried about the build system as >> far as a wrapping mechanism >> > > Do not under estimate the importance of build system integration. Tools >

On Wed, Jun 3, 2015 at 4:19 AM, Dave Bozier <seifsta at gmail.com> wrote: > Hi Teresa, > > Thanks for providing this updated RFC. > >> For Sony's linker, are you using the gold plugin or libLTO interfaces? >> If the latter, I suppose some ThinLTO handling would have to be added >> to your linker (e.g. to invoke the LLVM hooks to write the stage-2 >>

My earlier statement about wrapping things in a native object file held in that it is controversial. It appears to be still central to your design. It may help to look at the problem from a different viewpoint: LLVM is not a compiler. It is a framework that can be used to make compiler-like tools. >From that view, it no longer makes sense to discuss "the plugin," or gold, or $AR,

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 Wed, May 13, 2015 at 10:46 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > "ELF-wrapped bitcode" seems potentially controversial to me. > > What about ar, nm, and various ld implementations adds this requirement? > What about the LLVM implementations of these tools is lacking? > Sorry I can not parse your questions properly. Can you make it clearer? David

On Jun 1, 2015, at 6:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 29, 2015 at 6:15 PM, Sean Silva <chisophugis at gmail.com> wrote: >> >> >> On Fri, May 29, 2015 at 8:01 AM, Teresa Johnson <tejohnson at google.com> >> wrote: >>> >>> On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at

On Fri, May 29, 2015 at 8:01 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at leftfield.org> > wrote: > > My earlier statement about wrapping things in a native object file held > in that it is controversial. It appears to be still central to your design. > > > > It may help to look at the

> There is no need for emitting the full symtab. I checked the overhead with a huge internal C++ source. The overhead of symtab + str table compared with byte code with debug is about 3%. It's still sizable and could be noticeable if thinLTO can deliver compile times that closer to what resembles builds without LTO as your results suggest. > More importantly, it is also possible to use