search for: pruners

...shared library which was already unloaded. I thought we had fixed that, but maybe not?  Looking again, it looks like the patch got reverted and I didn't notice. -Eli On 5/14/2018 10:18 PM, Simone Atzeni via llvm-dev wrote: > This is the correct path to the pass: > https://github.com/PRUNERS/sword/blob/master/lib/Transforms/Instrumentation/InstrumentParallel.cpp > > On Mon, May 14, 2018 at 10:06 PM, Simone Atzeni <simone.at at gmail.com > <mailto:simone.at at gmail.com>> wrote: > > Hi all, > > I was porting my pass from LLVM 4.0 to 6.0 and I am...

...orting my pass from LLVM 4.0 to 6.0 and I am getting a segmentation fault. I was able to obtain only the info below from GDB. I tried to debug with some printf and the runOnFunction runs correctly. Any idea/suggestion about what is going on? The source code of the pass is here: https://github.com/PRUNERS/sword/blob/master/lib/Sword.cpp Any help is much appreciated, Thanks! Simone #0 0x00007f1d93735170 in ?? () #1 0x00000000017d2b96 in llvm::object_deleter<llvm::SmallVector<std::pair<llvm::PassManagerBuilder::ExtensionPointTy, std::function<void (llvm::PassManagerBuilder const&,...

This is the correct path to the pass: https://github.com/PRUNERS/sword/blob/master/lib/Transforms/Instrumentation/InstrumentParallel.cpp On Mon, May 14, 2018 at 10:06 PM, Simone Atzeni <simone.at at gmail.com> wrote: > Hi all, > > I was porting my pass from LLVM 4.0 to 6.0 and I am getting a segmentation > fault. > I was able to obtain onl...

...d. > > I thought we had fixed that, but maybe not? Looking again, it looks like > the patch got reverted and I didn't notice. > > -Eli > > > On 5/14/2018 10:18 PM, Simone Atzeni via llvm-dev wrote: > > This is the correct path to the pass: https://github.com/ > PRUNERS/sword/blob/master/lib/Transforms/Instrumentation/ > InstrumentParallel.cpp > > On Mon, May 14, 2018 at 10:06 PM, Simone Atzeni <simone.at at gmail.com> > wrote: > >> Hi all, >> >> I was porting my pass from LLVM 4.0 to 6.0 and I am getting a >> segmentat...

Hello, I am sending the following proposal to discuss issues and solutions regarding data races in concurrent ThinLTO processes. This caught my attention when we encountered a race condition in ThinLTO with caching. While looking into how ThinLTO deals with the problem of cache files reads/writes/deletes I spotted a lot of problems: some of them are related to data races, others - to

Le jeu. 22 mars 2018 à 16:46, Steven Wu <stevenwu at apple.com> a écrit : > Hi Katya > > Thanks for investigating this. Here is my thought inline. > > On Mar 22, 2018, at 1:32 AM, katya.romanova at sony.com wrote: > > > Hello, > > I am sending the following proposal to discuss issues and solutions > regarding data races in concurrent ThinLTO processes. >

Hi Katya Thanks for investigating this. Here is my thought inline. > On Mar 22, 2018, at 1:32 AM, katya.romanova at sony.com wrote: > > > Hello, > > I am sending the following proposal to discuss issues and solutions regarding data races in concurrent ThinLTO processes. > > This caught my attention when we encountered a race condition in ThinLTO with caching. >

> On Mar 26, 2018, at 6:03 PM, katya.romanova at sony.com wrote: > > Hi Steven, > Look at my replies inline (below your comments). > Katya. > > From: stevenwu at apple.com <mailto:stevenwu at apple.com> <stevenwu at apple.com <mailto:stevenwu at apple.com>> > Sent: Thursday, March 22, 2018 4:46 PM > To: Romanova, Katya <katya.romanova at sony.com

Hi Steven, Look at my replies inline (below your comments). Katya. From: stevenwu at apple.com <stevenwu at apple.com> Sent: Thursday, March 22, 2018 4:46 PM To: Romanova, Katya <katya.romanova at sony.com> Cc: Teresa Johnson <tejohnson at google.com>; Mehdi AMINI <joker.eph at gmail.com>; Rafael Avila de Espindola <rafael.espindola at gmail.com>; Peter Collingbourne

> On Mar 26, 2018, at 8:54 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > Le jeu. 22 mars 2018 à 16:46, Steven Wu <stevenwu at apple.com <mailto:stevenwu at apple.com>> a écrit : > Hi Katya > > Thanks for investigating this. Here is my thought inline. > >> On Mar 22, 2018, at 1:32 AM, katya.romanova at sony.com

From: stevenwu at apple.com <stevenwu at apple.com> Sent: Monday, March 26, 2018 11:58 PM To: Mehdi AMINI <joker.eph at gmail.com> Cc: Romanova, Katya <katya.romanova at sony.com>; Teresa Johnson <tejohnson at google.com>; Rafael Espíndola <rafael.espindola at gmail.com>; Peter Collingbourne <peter at pcc.me.uk>; Hans Wennborg <hans at chromium.org>; Reid

On Mon, Mar 26, 2018 at 6:03 PM, <katya.romanova at sony.com> wrote: > Hi Steven, > > Look at my replies inline (below your comments). > > Katya. > > > > *From:* stevenwu at apple.com <stevenwu at apple.com> > *Sent:* Thursday, March 22, 2018 4:46 PM > *To:* Romanova, Katya <katya.romanova at sony.com> > *Cc:* Teresa Johnson <tejohnson at

Hi Peter, Thank you for the clarification ☺. I’m sure you have a very good understanding of how much efforts it will take to write a patch for legacy C LTO to implement caching the same way it’s done in new C++ LTO API. How easy/difficult do you think it will be (very roughly, in LOC)? Do you anticipate that a lot of existing legacy C LTO infrastructure will have to be rewritten? Could this also

On Mon, Mar 26, 2018 at 7:34 PM, <katya.romanova at sony.com> wrote: > Hi Peter, > > > > Thank you for the clarification J. > > > > I’m sure you have a very good understanding of how much efforts it will > take to write a patch for legacy C LTO to implement caching the same way > it’s done in new C++ LTO API. How easy/difficult do you think it will be >

Hi Steven and Peter, I think we resolved all the misunderstanding/concerns that we had with the proposal and decided that we don’t have to implement heavy-weight synchronization solutions (such as read-write locks, etc). Lightweight solution is expected to work on MacOS and Windows (however, there might be issues with Windows supporting non-NTFS file systems). There are two options for the

Hi everyone, Here's an update on what we've been up to and how the LLVM 1.0 release is shaping up. Overall, things are going well, and it looks highly likely that we'll get the release out by the end of the month! Here's the hilights of the last few weeks: 1. John checked in support for building LLVM into multiple different object directories in the Autoconf style. He also