similar to: [NEW] LLVM / Clang Social in Chicago

Great, thanks! Are you planning on just talking about these things with slides? Do we have other things to which we can link for people to read? -Hal Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ________________________________ From: Tarique Islam <tislam at ca.ibm.com> Sent: Thursday, May 21, 2020 8:19:31 AM To:

Hi, everyone, We had a great call last month, and progress is definitely being made on several fronts. The notes from our last call are available here: https://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL50K-NvB6LfuBsfepBZ9Y/edit#heading=h.vpxs8lkuxy79 and, also, pasted below. DOODLE POLL: As we discussed on our last call, I would like to schedule a regular call to discuss

To join our call on Thursday, May 28th @ 9-10 AM central time / 2-3 PM UTC please use this information: Meeting URL https://bluejeans.com/643493129?src=join_info Meeting ID 643 493 129 Want to dial in from a phone? Dial one of the following numbers: +1.312.216.0325 (US (Chicago)) +1.408.740.7256 (US (San Jose)) +1.866.226.4650 (US Toll Free) (see all numbers -

Hi, everyone, A quick reminder: This call will start in approximately four hours. See below for how to join. On our current agenda: Agenda * Full restrict patch * Observation and clarification * Issues encountered * Speed up in intersection code - O(nlog(n)) * Calling Verifier after LoopVectorize pass? -Hal Hal Finkel Lead, Compiler Technology and Programming

Hi, everyone, We've had a number of discussions recently, including on the Flang technical call, about potential improvements to LLVM's alias analysis to support handling restrict and restrict-like semantics. We would like to try having a call to discuss these issues further. Please, if you're interested in joining, indicate your availability (prior to the end of this week):

Hi all, Thanks for the answers! I've also received a couple of answers off-list, so there should be enough of us to get something rolling. I think we should start with something informal to get to know each other and see what our interests are etc. So, I've created a poll with a random slice of March here [1], so we can sync on the date / time. Please pick as many options as you can. The

Hey, Anyone interested in organizing a meetup in Sweden? I'm based in Stockholm, but I don't mind traveling around on a weekend if people prefer to gather elsewhere. Cheers, Diana

I'd be interested in attending and helping organise the Hyderabad meetup. Cheers Siddharth On Wed 30 May, 2018, 14:32 Siddharth Shankar Swain via llvm-dev, < llvm-dev at lists.llvm.org> wrote: > Hi Folks, > > We are a group of LLVM compiler developers in Hyderabad area. Considering > few previous mail about meetups in India, we are planning to organize LLVM > meetups

It is my actual target architecture ________________________________ From: Doerfert, Johannes <jdoerfert at anl.gov> Sent: Saturday, March 23, 2019 1:30 PM To: J S Cc: via llvm-dev Subject: Re: [llvm-dev] Generating object files more efficiently I copied "-march=XYZ" from your original email, you have to replace it with your actual target architecture or simply drop it.

I will as well be interested in attending the meetup (in Hyderabad). IMHO we can start with Meetup and select a city. How are Meetups expenses generally handled elsewhere ? Regards,Pankaj Date: Wed, 30 May 2018 14:59:21 +0530 From: Madhur Amilkanthwar via llvm-dev <llvm-dev at lists.llvm.org> To: Siddharth Bhat <siddu.druid at gmail.com> Cc: Siddharth Shankar Swain <h2015096 at

Jay, Hiroshi, did [0] resolve the problem you've seen. [0] https://github.com/llvm/llvm-project/commit/d23c61490c282a7a8f29aaa5c021cbfdaf87fb6f On 12/10, Doerfert, Johannes wrote: > I think the problem is that only clang has a dependence on the new > library and when you check LLVM without building clang it does not exist > yet. I will commit a LLVM patch today that will cause LLVM

It seems the same bug is there if we do pointer swapping with selects. Do you agree? (see example below) define void @f() { entry: %a1 = alloca float, align 4 %a2 = alloca float, align 4 br label %loop end: ret void loop: %phi = phi i32 [ 0, %entry ], [ 1, %loop ] %select_cond = icmp eq i32 %phi, 0 %ptr1 = select i1 %select_cond, float* %a1, float* %a2 %ptr2 = select i1

Johannes, did you try it on AMD GPUs? If not, I think it might be early to claim it as a general interface for NVidia/AMD GPUs. I'm ok, if you want tointroduce a basic class for the GPU-specific codegen, but it must be done step-by-step and thoroughly tested and reviewed. Theremightbe some parts, common with NVPTX codegen. You can put the commonfunctions into a base class and remove them from

Yes, I understand. I just don't understand why there are 15 review links. as to the format of the list, we previously had a list of feature for 4.5 (before it was fully supported), we can reuse this old format. Best regards, Alexey Bataev > 6 июня 2019 г., в 19:12, Narayanaswamy, Ravi <ravi.narayanaswamy at intel.com> написал(а): > > Alexey, > Johannes want to put all

I don't know where it comes from, currently there is just 2 patches with the new functionality : mapper implementation in clang and in the runtime. Plus the patch for unified memory. Best regards, Alexey Bataev > 6 июня 2019 г., в 19:03, Doerfert, Johannes <jdoerfert at anl.gov> написал(а): > >> On 06/06, Alexey Bataev via llvm-dev wrote: >> Hmm, it is interesting.

-march for clang and -march for llc do different things unfortunately. -march for clang at least on x86 is the same as -mcpu in llc. Which is an artifact of gcc compatibility. ~Craig On Sat, Mar 23, 2019 at 1:40 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Oh, my bad. > > > Idk why llc seems to know that architecture but clang does not. > >

1. You don't need to implement everything in a single patch. The development process is a step-by-step process, when you commit something in small pieces. The code must nit be fully functional, you may start from some basic features. Currently it is very hard to review. 2. I rather doubt that it can be reused without changes for AMD etc., especially without being fully tested. The only tested

Hi folks, At EuroLLVM we had a round table for organizers of LLVM Socials around the globe. After the discussion we decided to get some sort of guidelines for those who want to organize the meetup in their city, but have any questions and don't know where to start. Currently, I am creating the very first draft. Once it's in a good shape I will send it to the phabricator. I am looking

AFAIK we are the only currently active group in Germany, but from following the list I spotted Johannes (Saarbrücken?) and Piotr (Munich?). They may have more info for you? Thx Am 14.10.16 um 14:18 schrieb picflo_2 at web.de: > Hi Stefan, > > thanks for detailed response. Would be quite interesting to see > different projects and tools in the LLVM ecosystem. > > By the way

Hi Folks, We are a group of LLVM compiler developers in Hyderabad area. Considering few previous mail about meetups in India, we are planning to organize LLVM meetups in India evry monthly or bimonthly in the best interest of other developers. Based on the concentration of developers Pune, Bangalore and Hyderabad are the location we have in mind. Interested folks please reply stating ur