similar to: [LLVMdev] Timing the IRReader

Ping? On Thu, Feb 28, 2013 at 12:59 PM, Eli Bendersky <eliben at google.com> wrote: > Hi, > > While doing various profiling runs of llc, it's easy to notice that > some wall-clock time is not accounted for by -time-passes (e.g. only 7 > out of 9.2 seconds for compiling gcc). Some of the "lost" time is in > reading the bitcode file (~ 1 sec). When reading

On Fri, Jul 29, 2016 at 5:41 AM, Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 29 July 2016 at 12:16, Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: > > 1) Leave the wording as is, and make Lanai an official back-end no > earlier > > than Sep 28th. > > I don't want to *have* to do that just because we introduced a policy

On Fri, Jul 29, 2016 at 10:00 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 29 July 2016 at 17:50, Eli Bendersky <eliben at google.com> wrote: > > While I think the 6-month mark is artificial (what's wrong about a vague > > "several months"? these are policies/guidelines, not legal contracts), > > I'm ok with that, too. > >

Hi All, While working on some recent patches for x32 support, I ran into an unpleasant limitation the LLVM eco-system has with testing DWARF emission. We currently have several approaches, neither of which is great: 1. llvm-dwarfdump: the best approach when it works. But unfortunately lib/DebugInfo supports only a (small) subset of DWARF. Tricky sections like debug_frame aren't supported. 2.

On 29 July 2016 at 17:50, Eli Bendersky <eliben at google.com> wrote: > While I think the 6-month mark is artificial (what's wrong about a vague > "several months"? these are policies/guidelines, not legal contracts), I'm ok with that, too. Though, what do you think about the "2 months after all done"? Maybe "at least 2"? Giving a number makes

On Fri, Sep 6, 2013 at 9:35 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi Eli > > I don’t know a workaround which will keep support for coloured terminal > output, but if you can live without it then passing these to configure > should work. > > --enable-curses=no > --enable-terminfo=no > > Re-doing the configure & build in a new directory solved

Hello, I'm trying to build some code that relies on LLVM as a library (out-of-source). It uses llvm-config for the compilation & linkage flags. Some recent change breaks it, and with the newest trunk LLVM I get: /home/eliben/llvm/build_llvm_svn_rw/Debug+Asserts/lib/libLLVMSupport.a(Process.o): In function `terminalHasColors':

Sorry for speaking too soon. It is missing from 3.2 which is the version I have been using. If it is already implemented than it is very good news. Thanks. -----Original Message----- From: Eli Bendersky [mailto:eliben at google.com] Sent: Monday, November 26, 2012 9:25 AM To: Manny Ko Cc: Albert Graef; Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] Removing old JIT

> > This reflects the compiler's view of things correctly, but is problematic > for a debugger. The debugger should know that arg_arr refers to a 42-element > array and isn't just a pointer into a buffer of unspecified length. This is > something the user would expect. > > On the other hand, the debugger should also get the information that > arg_arr is actually a

On Wed, Apr 17, 2013 at 10:23 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 4/17/2013 12:15 PM, Eric Christopher wrote: > >> >> Give a compelling argument and I might :) >> > > The cost is the extra time spent verifying that the binaries are fresh. > In my experience it has never happened that I ran "make check" on a wrong >

On 11/14/2017, 01:26 AM, Chris Bieneman wrote: > Sorry for the delayed response. I've been out of town a lot lately. > > The documentation you referenced is unfortunately out of date (you might notice it still references autoconf). I'll see if I can find time to update it, but the guidance should be to use the `llvm_config` CMake function instead. The proper usage of that in the

On Apr 17, 2013, at 10:43 AM, Eli Bendersky <eliben at google.com> wrote: > > > > On Wed, Apr 17, 2013 at 10:23 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 4/17/2013 12:15 PM, Eric Christopher wrote: > > Give a compelling argument and I might :) > > The cost is the extra time spent verifying that the binaries are fresh. In my

On Wed, Aug 14, 2013 at 1:15 PM, Tim Northover <t.p.northover at gmail.com>wrote: > > If anyone is interested in this support, I'd appreciate it if you changed > > your setup to use Python3 for running the tests and let me know (or file > > bugs) for any issues you find. > Great work, Daniel. All LLVM tests pass for me on trunk when running with Python 3.4 alpha.

>> > I'm fine with this as long as llvm-dwarfdump gets maintained. >> > >> >> I agree, and as I said in the original email, in the long term I >> believe llvm-dwarfdump is the correct solution. >> > > The problem is that if no one is working on testing these sorts of things > with llvm-dwarfdump then it won't be maintained for this

On Jan 17, 2013, at 10:30 AM, Eli Bendersky <eliben at google.com> wrote: > On Thu, Jan 17, 2013 at 10:20 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >> On Jan 17, 2013, at 9:57 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> >>> On Thu, Jan 17, 2013 at 7:51 PM, Sean Silva <silvas at purdue.edu> wrote: >>>> On Thu,

Hi Eli I don’t know a workaround which will keep support for coloured terminal output, but if you can live without it then passing these to configure should work. --enable-curses=no --enable-terminfo=no Thanks, Pete On Sep 6, 2013, at 9:09 PM, Eli Bendersky <eliben at gmail.com> wrote: > Hello, > > I'm trying to build some code that relies on LLVM as a library

Whoops... Seems I forgot the asterisk (*) after the cast. Or something. Because I did insert the cast and it didn't work. But NOW it works. Thank you for spending some time on this - and also for presenting the solution. -- Mikael 2013/12/4 Eli Bendersky <eliben at google.com> > This code: > > declare i32 @printf(i8* nocapture readonly, ...) nounwind > > define

On Tue, Jun 18, 2013 at 12:03 PM, Sean Silva <silvas at purdue.edu> wrote: > Instead of a blacklist, why not a whitelist? Given the size of LangRef, > you're bound to leave something out of your blacklist that needs to be > there (also, future additions to LLVM IR will need to be added to the > blacklist; are you sure you can catch *all* of them?). A whitelist seems >

> On Jun 24, 2015, at 10:19 AM, Eli Bendersky <eliben at google.com> wrote: > > > > On Wed, Jun 24, 2015 at 7:05 AM, Q Z <zhaoqian301 at gmail.com <mailto:zhaoqian301 at gmail.com>> wrote: > Hello，I want to compile a large project(for example,Apache httpd) to one .bc file. How can I do this? Can you give me some examples? > > > In general, if the

Hi Eli, Thanks for the link! I'm able to compile a standalone pass outside of the source tree, and I'm obviously ably to compile analysis groups inside the source tree. However, the problem comes when I try to do what the tutorial suggests to create an analysis group outside of the source tree. My understanding is that building out of tree requires different methods to register the