search for: dobbel

...ct__ data; }; void assign4(int *pA, long N) { int *__restrict__ x = pA; int tmp; { S s(x + N); tmp = *s.getData(); } *x = tmp; } I see that the full restrict implementation says that the load and the store do not alias. Is this by design? On Sat, Feb 15, 2020 at 9:00 AM Jeroen Dobbelaere < Jeroen.Dobbelaere at synopsys.com> wrote: > Hi Alexey, > > > > This is defined in 6.7.3.1 paragraph 4: > > '... Every other lvalue used to access the value of X shall also have its > address based on P ...' > > > > For 'assign1': &g...

...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 synopsys.com> wrote: > That's indeed a good example that shows that dropping the metadata (A) is > the only correct solution. > > > > Greetings, > > > > Jeroen Dobbelaere > > > > > > *From:* Finkel, Hal J. <hfi...

Hello, I would like to know what's the difference between Samba 3.X and Samba4? Is Samba4 ready to deploy (upgrade from 3.x) in production environments? Kind regards, Nico

...nels as extra operands and look at the number of operands to see if they are present or not - or maybe it is sufficient to look at the number of operands, and the noalias_sidechannel operand should be added with an extra bit, indicating if it is really there or not... Greetings, Jeroen Dobbelaere From: Alexey Zhikhartsev <alexey.zhikhar at gmail.com> Sent: Thursday, October 31, 2019 16:21 To: Jeroen Dobbelaere <dobbel at synopsys.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Full restrict support - status update Hi Jeroen, Thank you very much for the great...

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

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

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 'llvm LangRef' is concerned, this is invalid code: noalias This indicates that objects accessed via pointer values based<http://www...

...below for a consistency check only const SCEV *BackedgeTakenCount = SE->getBackedgeTakenCount(L); +#endif ----- It seems that the 'SE->getBackedgeTakenCount(L)' call has sideeffects.. Is that to be expected ? Is the correct solution then to always keep the call ? Thanks, Jeroen Dobbelaere

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

...scope. ## Future changes - Another request that came up during the round table, is to split up the documentation in two parts: a separate document describing the noalias architecture, and the LangRef, describing the intrinsics. I'll be working on that in the coming days. Thanks, Jeroen Dobbelaere [1] https://reviews.llvm.org/D68484 [PATCH 01/38] [noalias] LangRef: noalias intrinsics and noalias_sidechannel documentation. [2] https://reviews.llvm.org/D69542 Full Restrict Support - single patch

...13 Cand SU(12) ORDER Cand SU(13) ORDER In theory, schedules for vec_add and main should be the same right? Is there anything else I should do to make the __restrict remove loop-carried dependence in main? Attaching IR and scheduler log for reference... On Mon, Jun 22, 2020 at 3:03 PM Jeroen Dobbelaere < Jeroen.Dobbelaere at synopsys.com> wrote: > Hi Bandhav, > > > > as mentioned in the summary of https://reviews.llvm.org/D69542 : > > > > The base version is b2a37cfe2bda0bc8c4d2e981922b5ac59c429bdc > <https://reviews.llvm.org/rGb2a37cfe2bda0bc8c4d2e...