similar to: [RFC] How to manifest information in LLVM-IR, or, revisiting llvm.assume

On 12/18, John McCall wrote: > On 16 Dec 2019, at 18:16, Doerfert, Johannes via llvm-dev wrote: > > Abstract: > > > > It is often hard or impossible to encode complex, e.g., non-boolean, > > information in an `llvm.assume(i1)`. This RFC describes various problems > > we have right now and provides alternative design ideas. > > > > > > > >

Hi John, Is it correct to assume that you are in favor of - changing llvm.assume to be more expressive - operand bundle uses, especially w/o outlining - outlining, if we can show it plays well with transformations, e.g. the binding to the code is "weak" I inlined more comments below. On 12/18, John McCall wrote: > On 18 Dec 2019, at 11:28, Doerfert, Johannes wrote: >

Hi, Johannes, Thanks for working on this. This seems like a good approach which nicely extends the set of capabilities we have now. One additional comment, as I agree with everything in your rationale, except this: > - Reconstructing information from the pattern of instructions that feed > into the `llvm.assume` is also not optimal, especially since we do > not need to

Hi Alexey, >From: Alexey Zhikhartsev [..] > We would love to see your patches merged as soon as possible, so I was wondering: do you think the lack of bitcode support will prevent that from happening? Yes, I think that the lack of bitcode support will prevent it. During the Developers meeting, I also talked with Hal and Johannes. They had some extra remarks: - (1) the restrict

Hi Johannes et al, > -----Original Message----- > From: Doerfert, Johannes <jdoerfert at anl.gov> [..] > On 11/06, Jeroen Dobbelaere wrote: > > >From: Alexey Zhikhartsev > > [..] > > > We would love to see your patches merged as soon as possible, so I was > wondering: do you think the lack of bitcode support will prevent that from > happening? >

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):

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 -

Hello everyone, I've just uploaded a patch (https://reviews.llvm.org/D70261) to introduce a could of new token types to be used with constrained floating point intrinsics and, optionally, vector predicated intrinsics. These intrinsics may not be of interest to many of you, but I have a more general question. I would like some general feedback on the way I am proposing to use token arguments

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 Ulrich, Thank you for looking at this. Apologies again for taking unjustifiably long to get back to you. This is really good stuff and I very much want to see this go in. I like it enough I’m going to try to talk you into doing even more work on improving this code. ;) Fair warning up front: You’re digging into some pretty fundamental problems in how the assemblers and code generators like to

Hi Jim, > Thank you for looking at this. Apologies again for taking > unjustifiably long to get back to you. This is really good stuff and > I very much want to see this go in. I like it enough I’m going to > try to talk you into doing even more work on improving this code. ;) > > Fair warning up front: You’re digging into some pretty fundamental > problems in how the

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

We'd like to propose a scheme to attach "operand bundles" to call and invoke instructions. This is based on the offline discussion mentioned in http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-July/088748.html. # Motivation & Definition Our motivation behind this is to track the state required for deoptimization (described briefly later) through the LLVM pipeline as a

Thanks for the alternatives! I am trying the 'extracting sub-function' approach. However, it seems I can't get the 'subfunction' to pass the verifier. This is my subfunction: define void @main_extern([8 x i8]* %arg_ptr) { entrypoint: %0 = getelementptr [8 x i8]* %arg_ptr, i32 0 %1 = bitcast [8 x i8]* %0 to i64* %2 = load i64* %1 %3 = getelementptr [8 x i8]*

----- Original Message ----- > From: "David Majnemer" <david.majnemer at gmail.com> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames" > <listmail at philipreames.com>, "Chandler Carruth" > <chandlerc at gmail.com>, "Nick

As part of adding `"deopt"` operand bundles, we're aiming to change RewriteStatepointsForGC (called RS4GC henceforth) from rewriting existing `gc.statepoint` calls to transforming normal LLVM calls and invokes into `gc.statepoint` calls and invokes (i.e. to do PlaceSafepoints + RS4GC in one step). This will make `gc.statepoint` an artifact of the gc lowering strategy that only

Bingo! That works (when coming from C source) Now, I have a serious problem. I am not coming from C but I build the function with the builder. I am also forced to change the signature and load the pointers a,b,c afterwards: define void @bar([8 x i8]* nocapture readonly %arg_ptr) #0 { entrypoint: %0 = bitcast [8 x i8]* %arg_ptr to i32* %1 = load i32* %0, align 4 %2 = getelementptr [8 x

A high level summary of the proposal as it stands right now (from my perspective), after incorporating Philip's suggestions: 1. Operand bundles are a way to associate a set of SSA values with a call or invoke. 2. Operand bundles are lowered in some arbitrary bundle-tag specific manner. 3. The optimizer can optimize around operand bundles with (roughly) the assumption that

[+CC llvm-dev this time] Hi, As discussed in the review thread in http://reviews.llvm.org/D16439, the future plan around statepoints, deopt bundles, PlaceSafepoints etc. is to "constant fold" -spp-no-statepoints and -rs4gc-use-deopt-bundles to true. We (Azul) have moved to a representation of safepoint polls, deopt state etc. that enables us to do the above; and at this point I'm

----- Original Message ----- > Bingo! That works (when coming from C source) > > Now, I have a serious problem. I am not coming from C but I build the > function with the builder. I am also forced to change the signature > and > load the pointers a,b,c afterwards: > > define void @bar([8 x i8]* nocapture readonly %arg_ptr) #0 { > entrypoint: > %0 = bitcast [8 x