search for: chugunov

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:

...out <mutex> 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&g...

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 >> cons...

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>

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

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 >

...oblem. > > 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-pthread...

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

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 w...

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: &...

On Wed, Jun 25, 2014 at 3:30 PM, John Criswell <criswell at illinois.edu> wrote: > On 6/25/14, 5:15 PM, Vadim Chugunov wrote: > > 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. > > > Someone else emailed about t...

...ch lifetime.end() 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... >> >>...

...f this toolchain. 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:/...

...he picture. Something similar will likely happen in the AOT case, where the “code generator” just produces a subset of the data, and some other entity (the linker, say) incorporates that into the PDB. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Vadim Chugunov Sent: Wednesday, April 15, 2015 11:49 AM To: Russell Hadley Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MS fork Just curious, are you planning to add support for debug info emission in mspdb format? On Wed, Apr 15, 2015 at 7:01 AM, Russell Hadley <rhadley at microsoft.com<mailto:rhadl...

...t;http://reviews.llvm.org/D3418> D3419 SEH exceptions on Win64 (clang part) <http://reviews.llvm.org/D3419> D3420 MinGW toolchain <http://reviews.llvm.org/D3420> Per your suggestion the link to the original discussion in D3418 was added. Code authors are: unreachable is by Vadim Chugunov. win64 seh llvm is by Kai Nacke + Martell re-posting. win64 seh clang is by Martell. mingw toolchain is by Martell. register names is by Ray Donnelly + Martell posting it. seh test for "register names" ( test is r206566) by myself. All but the "register names" patch were posted...

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

...-26 3:15 GMT+03:00 Eric Christopher <echristo at gmail.com>: > On Wed, Jun 25, 2014 at 4:00 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Wed, Jun 25, 2014 at 3:30 PM, John Criswell <criswell at illinois.edu> > wrote: > >> On 6/25/14, 5:15 PM, Vadim Chugunov wrote: > >> > >> 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. &g...

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

...;>>> 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-...