search for: zhikhartsev

...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 work, it is much appreciated....

...*pA, long N) { > int *restrict x = pA; > > int tmp; > { > int *restrict y = x + N; > tmp = *y; > } > > *x = tmp; // may alias with *y > } > > Greetings, > > > > Jeroen Dobbelaere > > > > > > > > *From:* Alexey Zhikhartsev <alexey.zhikhar at gmail.com> > *Sent:* Friday, February 14, 2020 22:52 > *To:* via Llvm-dev <llvm-dev at lists.llvm.org> > *Cc:* Jeroen Dobbelaere <dobbel at synopsys.com>; hfinkel at anl.gov > *Subject:* Given one restrict pointer based on another, should they never...

Hi all, What's the current status of Attributor? How far is it from being enabled by default? Thanks, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200828/0abd04c3/attachment.html>

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....

Hi all, We noticed a lot of unnecessary ptrtoint instructions that stand in way of some of our optimizations; the code pattern looks like this: bb1: %int1 = ptrtoint %struct.s* %ptr1 to i64 bb2: %int2 = ptrtoint %struct.s* %ptr2 to i64 %bb3: %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] %ptr = inttoptr i64 %phi.node to %struct.s* In short, the pattern above arises due to: 1.

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

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? > > > > Yes, I think that the lack of bitcode support will prevent it. > > > >...

...fer it to be outside SROA, I think. > > > We should be *very* careful and restrictive about it. > > My initial thought is that the pattern below can be optimized > > but I haven't spend too much time on it. > > > ~ Johannes > > > On 7/2/20 11:26 AM, Alexey Zhikhartsev via llvm-dev wrote: >> Hi all, >> >> We noticed a lot of unnecessary ptrtoint instructions that stand in way of >> some of our optimizations; the code pattern looks like this: >> >> bb1: >> %int1 = ptrtoint %struct.s* %ptr1 to i64 >> >> bb2:...

Hello! I would like to debug Clang but avoid having to build LLVM with debug symbols enabled due to the size of the debug build which causes problems on the target system where I want to debug due to disk constraints. Is it possible to build LLVM and Clang but enable debug symbols for Clang only? If yes, how? Adrian PS: I'm only receiving digests on this list, so please keep me CC'ed.

...lt;llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Johannes et al, > -----Original Message----- > From: Doerfert, Johannes <jdoerfert at anl.gov<mailto: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? > > > > Yes, I think that the lack of bitcode support will prevent it. > > > >...

Hi everybody, I see a missed optimization opportunity in LLVM that GCC catches and I'd love to hear community's input. Here's the original C code: 1 char arr[2]; 2 char *get(unsigned ind) { 3 if (ind >= 1) { 4 return 0; 5 } 6 return &(arr[ind]); 7 } The variable `ind` is unsigned so, based on the comparison, if it is not greater or equals to one, than it is

Hi all, I would want to know if from the runOnFunction method of a Function pass, other functions in IR, except for the one received as parameter, can be obtained as well, from a call instruction, as follows: Function F = dyn_cast<Function>(callInst); Or do I need a Module pass to work in IR with multiple functions from input source code? If so, it is accepted to have O(n^3) complexity in a

...lt;llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Johannes et al, > -----Original Message----- > From: Doerfert, Johannes <jdoerfert at anl.gov<mailto: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? > > > > Yes, I think that the lack of bitcode support will prevent it. > > > >...

I agree with John; also, if you decide to go this route, you can reuse the code from CodeGenPrepare::optimizeSelectInst: https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/CodeGenPrepare.cpp#L6065 Alexey On Thu, Jan 30, 2020 at 9:00 PM John Regehr via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Several different passes introduce select instructions, such as >

...t;llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Johannes et al, > -----Original Message----- > From: Doerfert, Johannes <jdoerfert at anl.gov<mailto: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? > > > > Yes, I think that the lack of bitcode support will prevent it. > > > >...

On 4/29/20 4:12 PM, Reid Kleckner via llvm-dev wrote: > On Tue, Apr 28, 2020 at 12:58 PM Ejjeh, Adel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Specifically, I want to be able to know when a called function does not >> have any side effects (e.g. math library functions like sqrt) >> > > Apologies for the pedantry, but I believe sqrt may

Hi all, ## Status: During the past weeks I have updated the restrict patches with various improvements: - the ScopedNoAliasAA now also works together with the new pass manager - the SLPVectorizer now works nice with the noalias support. - there were some issues with some of the options enabling/disabling full restrict. These have been fixed. - various smaller enhancements. Today, I rebased the

...lt;llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Johannes et al, > -----Original Message----- > From: Doerfert, Johannes <jdoerfert at anl.gov<mailto: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? > > > > Yes, I think that the lack of bitcode support will prevent it. > > > >...