similar to: Given one restrict pointer based on another, should they never alias?

Thanks, Jeroen, that really helps. A follow-up question, if you don't mind. What if we have code somewhat similar to your example in assign3() but it's in C++ and the pointer derived from x is stored in a class member field: class S { public: S(int *d): data(d) {} int *getData() { return data; } private: int *__restrict__ data; }; void assign4(int *pA, long N) { int

My objective is to start having meta-data on objects that I create. For example, consider the following function: assign2 <- function(x, ...) { assign("x", ...) attr(x, "creation time") <- Sys.time() x <<- x } assign2("x", 1:4) "assign2" assigns to x the vector 1:4, and it then also adds the creation time of the object. (Hat tip goes to

On 06/28/2018 10:59 AM, Hal Finkel wrote: > Hi, Jeroen, > > We should move these conversations to llvm-dev so that they don't get > missed and others can contribute. Can I cc the list? [+llvm-dev] - Jeroen consented. > > Doing this will mean that the logic for when to remove dead llvm.noalias > intrinsics will become more complicated. That might be worthwhile. So >

> From: Eric Christopher > Subject: Re: [LLVMdev] How to associate extra comments to a > MachineInstruction ? > > Should be spelled like this yes? > > Asm->OutStreamer.AddComment("foo") > Asm->EmitFoo(); > > -eric That should work at the moment that you are emitting the instructions. But what would you do when you are manipulating a

Ok I think we have some common ground - CSE should choose the aliased pointer over the non-aliased one because we don't want the no-aliasing information to creep outwards from the inlined callsite. I'll put together a patch in the coming days and add y'all as reviewers so you get visibility. Cheers, -Neil. On Wed, Jan 22, 2020 at 4:47 PM Jeroen Dobbelaere < Jeroen.Dobbelaere at

Hi, I am trying to make my tablegen files more flexible and for that I would like to have a name that in the end will be replaced with a type. If tablegen would support c preprocssing, I would do it like this: --- #define myBaseType i32 ... def imm32 : Operand<myBaseType>; def immZExt10 : ImmLeaf<myBaseType, [{return isUInt<10>(Imm);}]>; ... --- Is there a way to achieve

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 -

Johannes, Thanks, I have been following along some of the thread(s) and the phab reviews. The scope of this work is more encompassing than our current needs and I've looked at trying to carve a piece out. It's not clear to me what purpose the llvm.noalias intrinsic serves right now. Also, if a mem instruction has !noalias metadata, then it should not be aliased, but I must be missing

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, is there a convenient way to associate/add a comment to a MachineInstruction, so that in the produced assembly file, the comment is added next to the instruction ? Greetings, Jeroen Dobbelaere

On Thu, May 30, 2013 at 2:16 PM, Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com> wrote: >> From: Eric Christopher >> Subject: Re: [LLVMdev] How to associate extra comments to a >> MachineInstruction ? >> >> Should be spelled like this yes? >> >> Asm->OutStreamer.AddComment("foo") >> Asm->EmitFoo(); >> >> -eric

Hi, I am investigating a difference in code generation between release and assert builds of llvm. The culprit is IndVarSimplify that comes up with different behavior on the same input: in the assertion build, it does do an extra 'INDVARS: Rewriting loop exit condition' After digging around, it seems that following change is the culprit: ----- Author: Philip Reames <listmail at

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

Hi, I am trying to get llvm working for an architecture that has 64bit registers, but 32bit addresses. Because of that, I want the pointers to also be 32bit, although they will live in a 64 bit register. On the frontend, I do not encounter any issues, but when I provide a ... "p:32:32:32" ... DataLayout specification to the backend, things get ugly: - SelectionDag is producing a

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

At a high level, EarlyCSE should be intersecting the metadata of instructions that it combines. If it doesn't, and also doesn't drop the metadata, that seems like a bug, regardless of anything else. On 1/22/20 9:30 AM, Jeroen Dobbelaere wrote: Hi Neil, Hall, - as far as 'C' is concerned, this is input code is valid, as the pointers are not used to modify objects. - as far as

Hi Hal, On Fri, Apr 4, 2014 at 12:44 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Jeroen Dobbelaere" <jeroen.dobbelaere at gmail.com> > [... ] > > I am trying to get llvm working for an architecture that has 64bit > > registers, but 32bit addresses. > > Because of that, I want the pointers to also be

Hi Alexey, Adding llvm-ir bitcode support means adding/adapting the tags for LOAD/STORE instructions and adding the support for the noalias_sidechannel at the right places. I had a short attempt to implement it when preparing the public patches, but I am not familiar with that part of the llvm code. When I noticed that it would take a lot longer than anticipated, I postponed it. Also because it

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 Ivan, The code that we have is indeed different from what the 'standard llvm' expects. Let me explain: in our version we came into this situation in two steps: 1) I added support for 'special types' that map directly to types supported by hardware. These types are represented by a struct containing a single iXXX member, providing the necessary bits of the type, and at the