similar to: Textual IR value names

And the clang behavior can be controlled with -fdiscard-value-names/-fno-discard-value-names ~Craig On Wed, Jan 9, 2019 at 2:16 PM Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, Jan 9, 2019 at 2:12 PM David Greene via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I like my LLVM IR text to have nice value names, e.g. > >

The names are dropped to save memory when a release build of the compiler is being used. This is what you probably want on a release compiler you intend to ship since it should be faster. The NDEBUG check is an easy way to tell the difference between release and debug builds. People probably don't want to have to remember to set an additional cmake option to make a release compiler faster.

Nick, Unfortunately this doesn't answer my question I don't think. It seems that -instnamer, as you mention, names the instructions but still does not name the local variables. So there really is no way to do this shy of creating (or basically copying) the API from AsmWriter (seems very dedundant to me)? This seems like a large failing? On Fri, Oct 21, 2011 at 7:03 PM, Nick

Nick, Is there a clean way to tell the difference between dst and src operands in operations without assignment "=" (ie, store)? On Mon, Oct 24, 2011 at 9:52 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Nick, > > I forgot to thank you, thanks! > > > On Sat, Oct 22, 2011 at 2:25 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > >> Ryan

On Mon, 27 Mar 2006, John Criswell wrote: > One consideration to weigh is that a debug build of LLVM provides users with > more diagnostic information to submit with bug reports (since many bugs are > caught by assertions, which print a readable stack trace). The tradeoff > seems to be faster and smaller LLVM tools (optimized build) vs. better > diagnostic information for bug

Hi, I am trying to locate the passes run by clang/opt when it is passed the option -O3. Can someone point me where to look at? Eventually, I want to turn off just the LoopStrengthReduction pass in the -O3 set of default passes. Thanks, Best Regards, Nitish -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I would like to propose, based on a previous discussion on llvm-dev, the following change. https://reviews.llvm.org/D56337 The main motivation for annotating member functions of ADT clases with LLVM_ALWAYS_INLINE was that of speeding up `check-llvm` at `-O0`. Turns out this significantly degrades the debuggability of fundamental classes in llvm itself, e.g. StringRef or SmallVector. After

Hi all, I'm hitting a segfault in llc when trying to build GHC: http://sprunge.us/ZVGB. What is the best way to debug this? I'm able to bump to 3.8.1 if needed, but GHC tends to break when updating major versions due to IR incompatibilities. Thanks, Shea -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size:

On Mon, 2006-03-27 at 11:47, Chris Lattner wrote: > On Mon, 27 Mar 2006, John Criswell wrote: > > One consideration to weigh is that a debug build of LLVM provides users with > > more diagnostic information to submit with bug reports (since many bugs are > > caught by assertions, which print a readable stack trace). The tradeoff > > seems to be faster and smaller

On Mon, 27 Mar 2006, Andrew Lenharth wrote: >> Another option is to build an optimized build with assertions on. Do to >> local demand, I added a build option 'make ENABLE_OPTIMIZED=1 >> ENABLE_ASSERTIONS=1' that provides this. > > How does this compare size and performance wise with a debug build or a > release build? I haven't done any scientific

Hi, Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100% accurate, but hopefully it helps to provide an overview of what's going on with compile time in LLVM and give a better understanding of what changes usually impact compile time.

On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <davide at freebsd.org> wrote: > > Shankar's parallel for per-se didn't introduce any performance benefit > (or regression). > If the change I propose is safe, I would like to see Shankar's change > in (and this on top of it). > I have other related changes coming next, but I would like to tackle > them one at

With the correct list this time. On Wed, Sep 9, 2015 at 6:59 PM, Davide Italiano <davide at freebsd.org> wrote: > Hi, > in the last month I spent some time implementing the missing MachO > specific features in llvm-readobj, and converting all the remaining > tests that used macho-dump to the new format. > llvm-readobj should have all the functionality that macho-dump had. If

While playing with sanitizer in a downstream project, I found out this. /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp:207:32: error: reference to type 'std::unique_ptr<MCCodeEmitter>' could not bind to an lvalue of type 'llvm::MCCodeEmitter *' UseDwarfDirectory, IP, CE, MAB, ShowInst));

I'm not entirely sure whether this is worth an RFC, but, just in case. On bugzilla Eli pointed out we currently match a specific sequence of instructions to cls ( https://reviews.llvm.org/rL206079), and given how fragile this is, it could be better to just introduce an intrinsic for it (and presumably, teach peephole optimizations to lower a sequence to that intrinsic). I wonder what folks are

Thank you. I went ahead with a speculative fix in r331568. I'm not familiar _at all_ with the tool, so, although the fix was straightforward, another pair of eyes from somebody familiar with the tool would be appreciated. On Fri, May 4, 2018 at 5:10 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > It worked in August. > Last time I’ve asked (again, in August) someone did

It worked in August. Last time I’ve asked (again, in August) someone did seem to care, but it is inevitable it would bitrot if it’s not built in any of the bots. George > On May 4, 2018, at 2:53 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > While playing with sanitizer in a downstream project, I found out this. > >

Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> writes: > No tests fail with the patch below, so I would say it's pretty useless. It > seems that the C bindings are the only user but we can probably just have them > return IPSCCP instead. I don't necessarily think your conclusion is wrong, but the patch isn't proving what you think it's proving. In fact, the

Hi everybody. NewGVN was recently committed and a few minute ago I added a flag to enable the new experimental pass. For the brave soul, passing `-mllvm -enable-newgvn` should do the trick. We'll be happy to receive bug reports to analyze/fix, bonus point if they contain a synthetic/reduced testcase. Open a bug linked to https://llvm.org/bugs/show_bug.cgi?id=30995 would be probably best so

On Mon, Dec 19, 2016 at 4:24 PM, Mikhail Zolotukhin <mzolotukhin at apple.com> wrote: > Hi Davide, > > Thanks for the analysis, it's really interesting! And I'm really glad that we now put more and more attention at the compile time! > > Just recently I've been looking into historical compile time data as well, and have had similar conclusions. The regressions