search for: bcain

...g info already exists, then reporting that as a > bug is appropriate. I can't say I'd be able to find time to try to *fix* > it before October, as I'm already over-committed, but I'd anticipate > getting to it around that time. > > --paulr > > > > *From:* bcain at codeaurora.org [mailto:bcain at codeaurora.org] > *Sent:* Thursday, August 23, 2018 3:18 PM > *To:* llvm-dev at lists.llvm.org > *Cc:* Robinson, Paul > *Subject:* [assembler + debuginfo] interaction with .file directive and > debuginfo > > > > [ I discussed this briefl...

...s 0.0622367858887 secs file rendering 8.30268716812 sec index rendering 2.08150291443 sec total time 63.9999139309 secs -Brian From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Adam Nemet via llvm-dev Sent: Thursday, November 17, 2016 11:15 AM To: Cain, Brian <bcain at quicinc.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Bob Haarman <inglorion at google.com> Subject: Re: [llvm-dev] Rewriting opt-viewer in C++ Hi Brian, Great, thanks for doing this! Can you please share the timing printouts? Are we spending most of the time in par...

[ I discussed this briefly with Paul off list and he suggested it would be better here. ] Among the changes in 7.0.0 are some that were added to support DWARFv5's .debug_line. The presence of ".file" mutes debug info generated by the assembler as of r328208 - logic in AsmParser::enabledGenDwarfForAssembly(). The comment there states: "If we haven't encountered

If the decision on whether this should swing Python or C++ is still open, here’s some food for thought: it’s trivially parallelizable. I lobbed some stuff in https://reviews.llvm.org/D26789 I used the pure python PyYAML and got a speedup of ~4x on my test case. I expect you might still be able to get an improvement with libYAML + a patch like this one. FWIW prior to this I also tried PyPy

llvm/cmake/modules/HandleLLVMStdlib.cmake specifies "-stdlib=libc++" for CMAKE_CXX_FLAGS when LLVM_ENABLE_LIBCXX and CXX_SUPPORTS_STDLIB. From what I can see this is a flag intended for the linker and not the compiler. I'd like to submit a change to delete CMAKE_CXX_FLAGS from this append() but I wanted to check in with the list to see if that makes sense or if there are other

That last post I see on this mailing list is from November <http://lists.llvm.org/pipermail/llvm-dev/2016-November/106941.html> concerning the results of the survey. So I was wondering what the latest status for moving to github? -- Wnk -------------- next part -------------- An HTML attachment was scrubbed... URL:

​Hi all, I am using llvmlite for pyvex and I want the output of my code (which is written based on llvmlite) to be like pyvex. In pyvex, (https://github.com/angr/pyvex). Considering pyvex, I tried to implement the following statements in pyvex to llvmlite: for stmt in irsb.statements: if isinstance(stmt, pyvex.IRStmt.Store): print "ST%s(%s) = %s" % (self.endness[-2:].lower(),

Hi My goal is that given a binary and the corresponding input. I want to know what IR level basic blocks are covered. I need the detail information, which is the set of all the covered BBs rather than just a number. I want to know whether there are some tools that can support this requirements. If not, I think maybe instrumentation can helps. However, I do not know too much about this. Any