similar to: [LLVMdev] [3.3 Release] 3.3rc3 Now Available

It's probably PR12517. Looking at the clang binary, it's got a /home/ dir in RPATH: $ objdump -p clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64/bin/clang | grep RPATH RPATH $ORIGIN/../lib:/home/aadgrand/tmp/LLVM-3.3rc3/rc3/Phase3/Release+Asserts/llvmCore-3.3-rc3.obj/Release+Asserts/bin This will slow things down if the system tries to automount /home/aadgrand. Maybe we should merge r182559

Hi Bill, I was running some benchmarks and was surprised that the startup performance of your binaries is much worse than the stable binaries for 3.2 I've used: http://llvm.org/releases/3.2/clang+llvm-3.2-x86_64-linux-ubuntu-12.04.tar.gz vs http://llvm.org/pre-releases/3.3/rc3/clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64.tar.gz On a simple hello.c file: /ssd/bench$ TIMEFORMAT="%E"

On Jun 6, 2013, at 9:04 AM, Hans Wennborg <hans at chromium.org> wrote: > It's probably PR12517. > > Looking at the clang binary, it's got a /home/ dir in RPATH: > > $ objdump -p clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64/bin/clang | grep RPATH > RPATH >

I'm not sure I follow. Will the final binaries have a bad RPATH or not? A 1sec startup pause on some (admittedly crazy) systems seems like a big deal to me. On Fri, Jun 7, 2013 at 6:51 AM, Bill Wendling <wendling at apple.com> wrote: > On Jun 6, 2013, at 9:04 AM, Hans Wennborg <hans at chromium.org> wrote: > > > It's probably PR12517. > > > >

On 06/06/2013 18:04, Hans Wennborg wrote:> It's probably PR12517. > > Looking at the clang binary, it's got a /home/ dir in RPATH: > > $ objdump -p clang+llvm-3.3rc3-Ubuntu-12.04.2-x86_64/bin/clang | grep RPATH > RPATH > $ORIGIN/../lib:/home/aadgrand/tmp/LLVM-3.3rc3/rc3/Phase3/Release+Asserts/llvmCore-3.3-rc3.obj/Release+Asserts/bin To avoid such behavior [1] , in

Hi Everybody, I'm working a project which requires assembly code for mips1 architecture for simulation purpose. I checked the latest LLVM3.2 version and found that the backend has been removed. I tried to replace the MIPS backed in LLVM3.2 by the old one in LLVM2.9 (which contains mips1) and adjust some routines to get the backend compiled. However, when llc is used to generate the assembly,

If you want to create a version for the mips1 subtarget, going back in time will probably be a lot of work for you. If you want to modify the current version you might try the following: 1) Create a Mips1 predicate and use that to disable instruction patterns that match using non Mips1 instructions. 2) Use soft-float 3) You would need to reenable some commented out code used to implement

My guess is he wants mips1 so that he doesn't have to worry about the patented mips instructions? At any rate, it will be a bit of work to enable a mips1 target and I doubt many people are interested, so it'll definitely be up to him to do the work. -eric On Fri, Apr 26, 2013 at 10:15 AM, Reed Kotler <rkotler at mips.com> wrote: > If you want to create a version for the mips1

On Wed, Mar 20, 2013 at 5:21 PM, Timur Iskhodzhanov <timurrrr at google.com>wrote: > 2013/3/20 Timur Iskhodzhanov <timurrrr at google.com>: > > Anton, > > > > [+Eric, Nick, > > the e-mail thread context has been broken a few times, so you should > > probably look at the llvmdev archives. > > It all starts here: > >

On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >> On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> I don't think this is the right approach. >>> >>> Currently we intentionally define malloc etc

Attached is a slightly updated patch. (it doesn't include D2222 yet). 2013/11/19 Eric Christopher <echristo at gmail.com>: > In general I do think we're going to need to abstract it out as much > as possible. I'm not sure what the previous patch looks like, but > abstracting the interface out would be general goodness for this. We > can talk about designs for that as

On Wed, Nov 20, 2013 at 9:46 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Eric, David, > > 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: >> Attached is a slightly updated patch. >> (it doesn't include D2222 yet). > > The new version of the patch stopped fitting into the llvmdev 100K limit, > so I've uploaded it to

>> > >> >> Probably the same structure that we've been going down via >> lib/DebugInfo/. A set of files than handle reading and parsing and >> both some binary files and some files produced by the backend. > > > Ooph, that's a big one. > Any more tips to prioritize diving into this codebase? > It mostly uses libObject to do the initial read

On Tue, Oct 2, 2012 at 11:02 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > On Tue, Oct 2, 2012 at 8:28 PM, David Blaikie <dblaikie at gmail.com> wrote: >> On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> [+cfe-dev as this does seem like both LLVM+Clang issue] >>> [Sorry for an incomplete e-mail context,

On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I don't think this is the right approach. > > Currently we intentionally define malloc etc without changing the > names and (when stuff works ok) the linker just links all the mem > allocator calls with calls to our RTL. This is kind of a link-time > interception. How could that work

Hi Timur, There's also a pending patch adding CodeView support in Phab: http://llvm-reviews.chandlerc.com/D165 Does your patch provide just a subset of the CodeView debug info provided in the other patch? Looking at the patch, I think the approach the other patch took of abstracting the emission of debug information is a bit cleaner and it will probably make life easier when adding more

http://llvm.org/bugs/show_bug.cgi?id=21241 ? 2014-10-23 10:18 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: > On Thu, Oct 23, 2014 at 1:15 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 1:13 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> Yes it is. >>> Are you doing a Debug or Release build?

Anton, What do you think? 2013/3/20 Eric Christopher <echristo at gmail.com>: > > > > On Wed, Mar 20, 2013 at 5:21 PM, Timur Iskhodzhanov <timurrrr at google.com> > wrote: >> >> 2013/3/20 Timur Iskhodzhanov <timurrrr at google.com>: >> > Anton, >> > >> > [+Eric, Nick, >> > the e-mail thread context has been broken a

On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > [+cfe-dev as this does seem like both LLVM+Clang issue] > [Sorry for an incomplete e-mail context, please see > http://llvm.org/PR13676#c6 if you're interested] > > I've read these bugs and now I'm even more confused than I was before :) > > What do you think about the

I think this issue is that we were not using the INTERCEPTOR macros to define these functions. The following patch seems to work for me to get the build linking again, however, I cannot test -- when I run check-asan, I get: 2> lit.py: lit.common.cfg:59: fatal: Invalid llvm_tools_dir config attribute: 'E:/llvm/2013/$(Configuration)/bin' ~Aaron On Thu, Oct 23, 2014 at 1:20 PM, Aaron