search for: pir

Hello, Below is a proposal for a GSoC project that I would like to work on this year. Your input and feedback is much appreciated. Background: ========= My name is Kareem Ergawy and I currently work as part of the PIR project. PIR is an extension of the IR to support fork-join parallelism that is currently under review [1, 2, 3, 4]. Goals: ===== As a GSoC project, here I propose an extension for llvm analyses and transformations to support parallel IR. Such extension should serve as a foundation for an optimi...

...e information, or work on a basic block level. To even further reduce changes to the existing passes, high-level concepts are broken down to already available low-level concepts instead of introducing new, semantically rich instructions/intrinsics (see the last paragraph of [5] and section 4 in the PIR white paper [6] for examples). Finally, this scheme allows a pass to simply reason about the sequential semantics of a parallel region, transform it back to one if needed or deemed beneficial and employ existing tooling solutions to debug and analyze the code [7]. (3) Comparison: The BoF discussio...

<mehdi.amini at apple.com>, Bcc: Subject: Re: [llvm-dev] [RFC][PIR] Parallel LLVM IR -- Stage 0 -- IR extension Reply-To: In-Reply-To: <20170224221713.GA931 at arch-linux-jd.home> Ping. PS. Are there actually people interested in this? We will continue working anyway but it might not make sense to put it on reviews and announce it on the ML if...

...made in the existing LLVM opt passes are < 200 LOC. ClangFE to executable end-to-end linked our omp library, and we also updated our implementation using token/tag on the intrinsics based on feedback from Google (David) and Xilinx (Hongbin). I am still owe Mehdi some answers. One feedback for PIR RFC, putting "fork" into loop body does not work for loop vectorizer, it shuts down vectorization, this is the same issue as MIT's scheme. Thanks, Xinmin -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Wednesday, March 8, 2017 5:51 AM To: Johannes D...

...8, 2017, at 10:55 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Mar 8, 2017, at 5:36 AM, Johannes Doerfert <doerfert at cs.uni-saarland.de> wrote: >> >> <mehdi.amini at apple.com>, >> Bcc: >> Subject: Re: [llvm-dev] [RFC][PIR] Parallel LLVM IR -- Stage 0 -- IR extension >> Reply-To: >> In-Reply-To: <20170224221713.GA931 at arch-linux-jd.home> >> >> Ping. >> >> PS. >> >> Are there actually people interested in this? I’m definitely interested too. I will have so...

...rg>; Sanjoy Das <sanjoy at playingwithpointers.com>; Mehdi Amini <mehdi.amini at apple.com>; Chandler Carruth <chandlerc at gmail.com>; Adve, Vikram Sadanand <vadve at illinois.edu>; TB Schardl <neboat at mit.edu>; acjacob at us.ibm.com Subject: Re: [llvm-dev] [RFC][PIR] Parallel LLVM IR -- Stage 0 -- On 03/08/2017 01:03 PM, Tian, Xinmin wrote: > The IR-region annotation we proposed is as below, there is no @llvm.parallel.for.iterator()..... There is no change to loop CFG. > > alloc A[100]; > %t = call token @llvm.region.entry()["paral...

...ng to do some policing in the ingress queue of the internet device. Until now we had configured some filters dividing traffic into queues, and on these queues the Double Leaky bucket meter was applied. The idea is to have a minimum of bandwidth assigned per class (the cir values) and a maximum (pir values), just as with the HTB meter. (see ''code 1'' at the bottom of the mail for the configuration). However after reading in the ''Traffic Control - Next generation reference Manual'' - p41 of the nov 20, 2003 release - I understood (correct me if I''...

...x (Hongbin). I am still owe Mehdi some > answers. Thanks for the update. I will look into the discussion thread again soon. I am especially interested in the problem Mehdi pointed out regarding the missed initializations of array elements, did you comment on that one yet? > One feedback for PIR RFC, putting "fork" into loop body does not work > for loop vectorizer, it shuts down vectorization, this is the same > issue as MIT's scheme. Totally true. The vectorizer needs to be thought about the fork-join at some point. However, you can for now sequentialize and introdu...

...anjoy Das <sanjoy at playingwithpointers.com>; Mehdi Amini <mehdi.amini at apple.com>; Chandler Carruth <chandlerc at gmail.com>; Adve, Vikram Sadanand <vadve at illinois.edu>; TB Schardl <neboat at mit.edu>; acjacob at us.ibm.com >> Subject: Re: [llvm-dev] [RFC][PIR] Parallel LLVM IR -- Stage 0 -- >> >> >> >> On 03/08/2017 01:03 PM, Tian, Xinmin wrote: >>> The IR-region annotation we proposed is as below, there is no @llvm.parallel.for.iterator()..... There is no change to loop CFG. >>> >>> alloc A[10...

...i some >>> answers. >> Thanks for the update. I will look into the discussion thread again soon. I am especially interested in the problem Mehdi pointed out regarding the missed initializations of array elements, did you comment on that one yet? >> >>> One feedback for PIR RFC, putting "fork" into loop body does not work >>> for loop vectorizer, it shuts down vectorization, this is the same >>> issue as MIT's scheme. >> Totally true. The vectorizer needs to be thought about the fork-join at some point. However, you can for now se...

...n). I am still owe Mehdi some answers. > Thanks for the update. I will look into the discussion thread again soon. I am especially interested in the problem Mehdi pointed out regarding the missed initializations of array elements, did you comment on that one yet? > > > One feedback for PIR RFC, putting "fork" into loop body does not > > work for loop vectorizer, it shuts down vectorization, this is the > > same issue as MIT's scheme. > Totally true. The vectorizer needs to be thought about the fork-join at some point. However, you can for now sequential...

...terator I = AnalysisImpls.begin(); (I!=AnalysisImpls.end()); ++I) { if (I->first==PI && I->second==P) { // Return, if PassInfo and Pass are already in AnalysisImpls. return; } } std::pair<const PassInfo*, Pass*> pir = std::make_pair(PI,P); AnalysisImpls.push_back(pir); } I'm probably doing something funny, or not as intended, but your comments would be appreciated. Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attac...

Hi Johannes, > I am especially curious where you get your data from. Tapir [0] (and to > some degree PIR [1]) have shown that, counterintuitively, only a few changes > to LLVM passes are needed. Tapir was recently used in an MIT class with a > lot of students and it seemed to work well with only minimal changes > to analysis and especially transformation passe...

I'm getting permission denied for; ftp://ftp5.freebsd.org/pub/FreeBSD/ports/i386/packages-4-stable/ The welcome message on the machine says; If there are any problems with this server, please send mail to %E. Who should I let know about this so it actually gets seen ? Ta, P. -- pir pir-sig@pir.net pir-sig@net.tufts.edu

I found some ancillary information that seems to indicate that there is a driver that will allow a D-Link DGE-550SX Gigabit fiber NIC to work under FreeBSD 4.x. Can anyone confirm or refute this, or provide additional information? If the NIC is not supported, is there a recommendation for a gigabit fiber NIC that works well under 4.8? Thanks, Steve

On updating to recent -STABLE I get; WARNING: driver fw should register devices with make_dev() (dev_t = "#fw/0") I'd assume this would be a good thing to fix before 4.9-REL ships and there are questions from everyone who uses firewire ... P. -- pir pir-sig@pir.net pir-sig@net.tufts.edu

...4.9-STABLE (as of today) and it hangs on boot after the apm0 line. It's doing SMP and the motherboard has hyperthreading enabled. It won't break out to the kernel debugger so I can't get a kernel dump. Clues ? Known issue ? P. FreeBSD 4.9-STABLE #6: Mon Nov 17 18:02:33 EST 2003 pir@falcon:/usr/src/sys/compile/SWORKS Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) XEON(TM) CPU 2.40GHz (2395.92-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,...

On 9 March 2015 at 17:30, Tobias Grosser <tgrosser at inf.ethz.ch> wrote: > If my memories are right, one of the critical issues (besides > other engineering considerations) was that parallelism metadata in LLVM is > optional and can always be dropped. However, for > OpenMP it sometimes is incorrect to execute a loop sequential that has been > marked parallel in the source

...gt;      { > >         if (I->first==PI && I->second==P) > >         { > >            // Return, if PassInfo and Pass are already in AnalysisImpls. > >            return; > >         } > >      } > >     std::pair<const PassInfo*, Pass*> pir = std::make_pair(PI,P); > >     AnalysisImpls.push_back(pir); > >   } > > > > I’m probably doing something funny, or not as intended, but your comments > would be appreciated. > > > > Rob. > > _______________________________________________ > LLVM Dev...

...that this approach causes me are that basic analyses like > dominance, reachability and the like are broken Yes, intrinsics are heavy handed and will stop the compiler from being smart in many ways. > One possibility to do this gradually might also be to have a seperate, parallel, IR, say PIR, that will be > lowered to regular IR at some point (however this point is chosen). So, we have Polly that does that, and it's not a trivial issue. Adding yet another representation is worrying. The IR Language Reference is comprehensive and authoritative, and is a great resource for buildi...