search for: laevsky

Hi Igor, On Oct 17, 2016, at 10:39 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: Hi Michael, Hi Igor, Hi Michael, Hi Michael, What I was referring to is that we can write somethi...

> On 20 January 2016 at 09:21, Igor Laevsky via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> Not so long ago we have found ourselves in need of a robust _eh_frame parser. All we wanted is the ability to parse .eh_frame section emitted by LLVM's MCJIT. Considering this, LLVM would be a natura...

...think the changes are good. We can work on integrating those after landing the original patch (assuming its eventually ok to do so). Thanks, Pete > On Jan 20, 2016, at 6:58 AM, Rafael Espíndola via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 20 January 2016 at 09:52, Igor Laevsky <igor at azulsystems.com> wrote: >>> On 20 January 2016 at 09:21, Igor Laevsky via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>>> Hi all, >>>> >>>> Not so long ago we have found ourselves in need of a robust _eh_frame parser....

> On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com> wrote: >> >> Hi Michael, > Hi Igor, Hi Michael, > >> >> +CC llvm-dev >> >> My guess is that it would be rather error prone to pinpoint exact places where we start populating new LPPassManager since it’s created lazily v...

Hi all, Not so long ago we have found ourselves in need of a robust _eh_frame parser. All we wanted is the ability to parse .eh_frame section emitted by LLVM's MCJIT. Considering this, LLVM would be a natural place for implementing such parser. Previous email thread about the issue (https://groups.google.com/forum/#!topic/llvm-dev/Vb_VYU7Eo0k) showed some interest among the community. Folks

...hink? > > For now I don't have a good idea on how to utilize PassManager to schedule such verifiers automatically though:-( > > - Michael > > PS: Did you mean to send it to the list? Chandler might have good ideas here. > > >> On Oct 13, 2016, at 8:30 AM, Igor Laevsky <igor at azulsystems.com> wrote: >> >> Hi Michael, >> >> In the https://reviews.llvm.org/D25364 we were discussing possibility of verifying LCSSA only for the top-level loops. I started implementing this but process appears to be a bit tricky. Problem is that I can’t...

Hi, LLVM's memory intrinsics are quite useful for performing various optimizations with frequently used memory operations. Unfortunately this intrinsics are not applicable for languages with guaranteed atomicity for their memory accesses (like Java for example). In order to overcome this limitation I'm thinking about adding set of intrinsics which will execute as a series of unordered

Hi, Currently in AliasAnalysis we can model ModRef behaviour for functions which only access memory through their pointer arguments. However we can't express this propery as a function attribute. For example, for intrinsics we can specify ReadWriteArgMem or ReadArgMem attributes in tablegen definitions. But due to the lack of the related function attributes on the llvm ir level, this

...that's used with catchpads and basically do the same thing with landingpads. Thanks -Joseph From: Chen Li [mailto:meloli87 at gmail.com] Sent: Saturday, December 5, 2015 12:34 AM To: Joseph Tremoulet <jotrem at microsoft.com> Cc: David Majnemer <david.majnemer at gmail.com>; Igor Laevsky <igor at azulsystems.com>; llvm-dev <llvm-dev at lists.llvm.org>; John McCall <rjmccall at apple.com> Subject: Re: Support token type in struct for landingpad On Dec 4, 2015, at 1:27 PM, Joseph Tremoulet <jotrem at microsoft.com<mailto:jotrem at microsoft.com>> wrote...

...a single > parser used by all llvm tools. Absolutely. We'll get to that stage, I hope. We'll need to work out if there's a way to abstract what we need from each client without slowing down or complicating any of them too much. Pete > > On Wed, Jan 20, 2016 at 2:21 PM, Igor Laevsky via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> Not so long ago we have found ourselves in need of a robust _eh_frame parser. All we wanted is the ability to parse .eh_frame section emitted by LLVM's MCJIT. Considering this, LLVM would be a natura...

...least disruptive and most explicit/straightforward about the personality's expectations, but I'm curious what others think. Thanks -Joseph From: Chen Li [mailto:meloli87 at gmail.com] Sent: Thursday, December 3, 2015 4:06 PM To: David Majnemer <david.majnemer at gmail.com> Cc: Igor Laevsky <igor at azulsystems.com>; llvm-dev <llvm-dev at lists.llvm.org>; Joseph Tremoulet <jotrem at microsoft.com> Subject: Re: Support token type in struct for landingpad Hi David and Joseph, I’ve just added landingpad with token type locally and changed gc.relocate to work in the fo...

Hi, I was very curious so I went ahead and resubmitted Pete’s original change. So far no buildbot failures, looks promising. On 26 January 2016 at 09:19, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Sent from my iPhone On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at

> On Dec 1, 2015, at 11:14 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > While we support 'opaque' types nested within struct types, they are not exactly battle tested: > > $ cat t.ll > %opaque_ty = type opaque > > %struct_ty = type { i32, %opaque_ty } > > define %struct_ty @f(%struct_ty* %p) { > %load = load %struct_ty,