similar to: Full restrict support - status update

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, 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 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 Jeroen, Sorry, I missed that. I tried the patch, and this program: #include <stdint.h> #define __remote __attribute__((address_space(1))) __remote int* A; __remote int* B; void vec_add(__remote int* __restrict a, __remote int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } int main(int argc, char** argv) {

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, I'm trying to abstract some special pointers with a class, like in the example program below: 1 #define __remote __attribute__((address_space(1))) 2 #include <stdint.h> 3 4 __remote int* A; 5 __remote int* B; 6 7 class RemotePtr { 8 private: 9 __remote int* __restrict a; 10 11 public: 12 RemotePtr(__remote int* a) : a(a) {} 13 14 __remote

Hi Jeroen, That's great! I was trying to use the patch, what's the latest version of the project we could apply it on? Hi Neil, That seems like what I can do as well! Do you happen to have some examples lying around? Maybe a pointer to the planned presentation, if that's okay? Thank you, Bandhav On Mon, Jun 22, 2020 at 1:55 AM Neil Henning <neil.henning at unity3d.com>

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

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

I'm having an issue where SROA will throw away no-alias information on some loads after inlining, because the loads are derived from a store to an alloca which can be removed after inlining. The pointers that were originally stored into the alloca do *not *have any aliasing information - the only context that allowed me to assert aliasing was that the inlined-function guaranteed it to be so.

Unfortunately https://llvm.org/docs/LangRef.html#llvm-loop-parallel-accesses-metadata is not a solution here. A loop-parallel access does not imply non-aliasing. The obvious case is when only reading from a location, but even when a location is written to I'd be careful to deduce that they do not alias since it might be a "benign data race" or the value never used. Additionally,

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

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 >

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, We, IBM XL Fortran compiler team, is interested in representing Fortran alias information in LLVM IR. We use the XL Fortran frontend to emit LLVM IR that includes alias information to feed to the LLVM in order to create object files. For the Fortran alias representation in LLVM IR, we considered both TBAA and ScopeAlias/NoAlias metadata approaches, we think that the ScopeAlias/NoAlias

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

Hi all, I am happy to announce that Synopsys wants to contribute its implementation of 'C99 restrict' to the LLVM project. [1] This implementation is based on Hal Finkel's local restrict patches and on the 'RFC: Full 'restrict' support in LLVM' [2] Any help with extra testing and code review is welcome. To be generally useful, there are also some small gaps [1] that

We recently found an issue when using the full restrict implementation developed by Jeroen; it surfaces when compiling an obscure combination of std::valarray and std::indirect_array but I don't want to bore you with all the details. What it boils down to is this basic question about restrict: Given one restrict pointer based on another, should they never alias? As far as I understand the