similar to: [LLVMdev] Machine basic blocks

Hi All, For various obscure reasons I'd like to detect the condition when X86 CALL instruction immediately precedes a function epilogue in the final emitted code, and insert a NOP between them if that happens. My initial attempt at it looked like this: MachineBasicBlock& MBB; MachineBasicBlock::iterator MBBI; <-- points to where the epilogue would be inserted if (MBBI != MBB.begin()

Hi Reid, Is this design supposed to be able to cope with asynchronous exceptions? I am having trouble imagining how this would work without adding the ability to associate landing pads with scopes in LLVM IR. Vadim On Tue, Nov 25, 2014 at 5:27 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 25, 2014 at 3:09 PM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:

When LLVM's configure finds a usable <pthread.h>, it prefers to use that rather than the home-grown stuff. However if LLVM is configured with --disable-pthreads, both mingw flavors produce the same results. BTW, I've tried to quantify the slowdown: a quick test indicates that LLVM build that uses pthreads is about 10% slower than the one which doesn't. This is less that I

If we added unwind target to every potentially throwing instruction (loads, stores, all binary operations), wouldn't all such instructions have to become BB terminators? I'd expect that CFG would then end up consisting mostly of single-instruction BBs. This can't be good for compilation performance and optimizations... Another vague idea: what if lifetime.start() returned some kind

Hi, Is it somehow possible to have LLVM emit machine code for the 'unreachable' IR instruction, which would assert that it indeed never gets reached? Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140414/02108a74/attachment.html>

Hi, Having just found an ABI conformance bug in a compiler front-end, I am curious: is the state of target-independent argument lowering in LLVM still the same as when this thread was taking place?: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387 Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL:

I am not seeing this happening, at least not for unreachables that follow calls to 'noreturn' functions. On Apr 14, 2014, at 3:48 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > x86 backend emits ud2 instruction in this case > > On Mon, Apr 14, 2014 at 1:46 PM, Vadim Chugunov <vadimcn at gmail.com> wrote: >> Hi, >> Is it

Hi Yaron, Not sure I understand your question. Wasn't <mutex> one of the more important C++11 features that LLVM would like to use? On Thu, Sep 25, 2014 at 1:24 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > Vadim, > > Thanks for the feedback on the -win32. A dependency on a small DLL with > BSD license does not sound too bad, but performance regression is

On Wed, Dec 3, 2014 at 1:41 PM, Reid Kleckner <rnk at google.com> wrote: > On Wed, Dec 3, 2014 at 1:27 PM, Vadim Chugunov <vadimcn at gmail.com> wrote: > >> If we added unwind target to every potentially throwing instruction >> (loads, stores, all binary operations), wouldn't all such instructions have >> to become BB terminators? I'd expect that CFG

Hi! LLVM has a class, ConstantExpr, that is very handy for compile-time evaluation of const expressions. Unfortunately I cannot find any methods in it that would be helpful in evaluation of expressions similar to this: (uintptr_t)(&(*(TYPE*)0).FIELD), which is basically the implementation of the offsetof(TYPE, FIELD) macro. Specifically, there seem to be no provisions for dereferencing a

On Fri, Jan 2, 2015 at 2:20 AM, David Majnemer <david.majnemer at gmail.com> wrote: > > > On Fri, Jan 2, 2015 at 1:58 AM, Vadim Chugunov <vadimcn at gmail.com> wrote: > >> Hi! >> LLVM has a class, ConstantExpr, that is very handy for compile-time >> evaluation of const expressions. Unfortunately I cannot find any methods >> in it that would be

+llvmdev. I find this pretty surprising. Actually, we already use std::mutex and std::recursive_mutex in clang, lld, and other llvm projects, it's just a coincidence that it hadn't been introduced into LLVM until my commits. I'm not sure what the right thing to do here is. If I understand correctly, it seems like in order to encounter this, a) you must be using GCC, b) you must be

Hello, In continuation of several threads from the last week, I'd like to ask: is there a stated plan of what is going to happen with compiler-rt in the near future? In particular, I'm interested if any of the following is planned to happen: - Separation from clang I've seen a suggestion to rename compiler-rt to "libclang_rt", but its' applicability is much broader than

Hi, I think I can at least answer why the Rust project prefers to use mingw-w64-win32threads: 1. It does not inject dependency on libwinpthread.dll, which is nice. 2. Those who tried building LLVM with mingw-w64-pthreads, had reported significant slowdown of the resulting Rust compiler (as compared to one linked to LLVM compiled with the win32threads flavor). Profiling seemed to point towards

Hi David, On Wed, Feb 12, 2014 at 5:22 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 12 Feb 2014, at 13:21, Alexey Samsonov <samsonov at google.com> wrote: > > > On Wed, Feb 12, 2014 at 4:56 PM, David Chisnall < > David.Chisnall at cl.cam.ac.uk> wrote: > >> Are you going to move the unwind library there as part of the >

Hi, On 15.04.2014 23:44, Vadim Chugunov wrote: > Hi, > I am curious - how does clang deal with epilogue-less functions that > result from _Raise_Exception being marked 'noreturn'? > I've also been playing with Kai's patch, and discovered that this tends > to greatly confuse Windows stack unwinder in cases when noreturn call is > at the end of a function, so

Sorry, I mean only disable this for THREADS-WIN32, not threads-posix. On Fri, Jun 20, 2014 at 11:14 AM, Zachary Turner <zturner at google.com> wrote: > #2 is better if we can detect threads-win32 vs threads-posix on MinGW, and > only disable this for threads-posix. We can check for > _GLIBCXX_HAS_GTHREADS, but that seems somewhat hackish, so I wonder if > there's a better

In a recent review via Phabricator, I was receiving bounce notifications for mail being sent to llvm-commits because of "Too many recipients to the message", even though I am a subscriber. I wonder how common is that. On Wed, Jun 25, 2014 at 12:03 PM, Manuel Klimek <klimek at google.com> wrote: > I am prioritizing email issues. Please always make sure to send them >

It sounds like this version of libstdc++ doesn't support std::recursive_mutex from C++11. This is really unfortunate, because we were hoping that moving to C++11 would allow us to use standard, portable threading primitives. Does this version of MinGW have any C++11 threading support? Is it just recursive_mutex that is missing, or do we have to avoid std::mutex, std::call_once, etc? lld

The LLILC project does not require direct interaction with the PDB, so it’s not part of our plans. The JIT uses a special reporting format to communicate debug info (frame info and machine->IL mappings) back to the CoreCLR EE. The debugger joins this with the frontend-produced debug information (IL->source and logical frame offset->local, which is in a PDB) to complete the picture.