search for: vadimcn

...> and <thread> on win32threads, why > should it slow down on pthreads? > Isn't the only difference betwen the win32threads and pthreads is the > addition of pthreads, <mutex> and <thread>? > > Yaron > > > 2014-09-26 11:39 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>: > >> 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> > wrot...

...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 somehow possible to have LLVM emit machine code for the 'unreachable' >> IR instruction, which would assert that it indeed never gets reached? >> >> Vadim >> >> _______________________________________________...

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>

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 would then end up >> consisting mostl...

...gt; However, by disabling <mutex> use with -pthreads rust performance should > be same as -win32 threads? > Saying it another way, does the -win32 version have any feature that > -pthreads vesion do not have? > > Yaron > > > 2014-09-25 9:52 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>: > >> 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 repor...

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 helpful in evaluation of expressions similar to this: >> (uin...

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:

...nd() has to consume? That would prevent transformations that don't preserve lifetime scopes (such as the one you've described), wouldn't it? Vadim On Wed, Dec 3, 2014 at 12:55 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Dec 2, 2014 at 6:05 PM, Vadim Chugunov <vadimcn at gmail.com> wrote: > >> Sure, but memory access violations are not the only source of >> asynchronous exceptions. There are also stack overflows, integer overflows >> (on platforms that support that in hardware), signaling NaNs, and so on... >> >> I am curious...

...ain always walkable? - Can frame pointers be disabled on a per-function basis? (this is in case not the whole program's stacks need to be made relocatable). Vadim On Thu, Jan 23, 2014 at 8:22 AM, Mark Seaborn <mseaborn at chromium.org> wrote: > On 22 January 2014 22:10, Vadim <vadimcn at gmail.com> wrote: > >> Hi, >> I am toying with an idea of having LLVM generate code that has >> position-independent stacks. This would be a very useful property for >> implementing all sorts of micro-thread libraries (I am thinking something >> similar to P...

...ain. Only if all 3 of those are true, then std::mutex and std::recursive_mutex don't exist. Anybody else have thoughts on whether this necessitates reverting the mutex changes, or whether this toolchain configuration should be supported? On Fri, Jun 20, 2014 at 12:07 AM, Vadim Chugunov <vadimcn at gmail.com> wrote: > FYI - this commit broke LLVM build using [[ > http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo > | win32 threads ]] flavor of the mingw toolchain. I am getting [[ > http://stackoverfl...

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! 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

Hi, I have a couple of questions about MachineBasicBlocks: - If I have a pointer to an MBB, is there an easy way to find which block that precedes it in the MachineFunction blocks list? (without iterating through all of the MF's basic blocks) - Does LLVM make any effort to ensure that MBB's predecessors and successors lists are semantically correct? For example, what happens if an MBB

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 am toying with an idea of having LLVM generate code that has position-independent stacks. This would be a very useful property for implementing all sorts of micro-thread libraries (I am thinking something similar to Python greenlets <http://stackoverflow.com/a/17447308>), because you'd be able to easily save threadlet state from one OS thread and later restore it into another.

...Anybody else have thoughts on whether this necessitates reverting the >>>>>> mutex changes, or whether this toolchain configuration should be supported? >>>>>> >>>>>> >>>>>> On Fri, Jun 20, 2014 at 12:07 AM, Vadim Chugunov <vadimcn at gmail.com> >>>>>> wrote: >>>>>> >>>>>>> FYI - this commit broke LLVM build using [[ >>>>>>> http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-wind...

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:

...utex and std::recursive_mutex don't exist. >> >> Anybody else have thoughts on whether this necessitates reverting the >> mutex changes, or whether this toolchain configuration should be supported? >> >> >> On Fri, Jun 20, 2014 at 12:07 AM, Vadim Chugunov <vadimcn at gmail.com> >> wrote: >> >>> FYI - this commit broke LLVM build using [[ >>> http://stackoverflow.com/questions/13212342/whats-the-difference-between-thread-posixs-and-thread-win32-in-gcc-port-of-windo >>> | win32 threads ]] flavor of the mingw toolchain....

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 >