similar to: [RFC] dereferenceable metadata

Indeed. But the problem here is that Dinar is trying to keep information after a load/store is removed by instcombine For example: v4sf v = {p[0], p[1], p[2], p[3]}; v4sf v2 = shuffle(v, 0, 0, 2, 2); Some pass comes in and removes the p[3] and p[1]. Now you have smaller code, but lost the ability to use a vector load for all those values + shuffle. The code got scalarized because we lost the

On 09/26/2017 08:31 AM, Dinar Temirbulatov wrote: > Hi Hal, >> Are you primarily concerned with being able to widen loads later in the pipeline? Could we attached metadata to the remaining loads indicating that it would be legal to widen them? > no, I don't have any concerns about intrinsic way of implementation, > and intrinsic way looks safer for me since we somehow detach our

Hi Hal, >Are you primarily concerned with being able to widen loads later in the pipeline? Could we attached metadata to the remaining loads indicating that it would be legal to widen them? no, I don't have any concerns about intrinsic way of implementation, and intrinsic way looks safer for me since we somehow detach our information about memory from that actual load instruction. I updated

Hi, For PR21780 solution, I plan to add a new functionality to restore memory operations that was once deleted, in this particular case it is the load operations that were deleted by InstCombine, please note that once the load was removed there is no way to restore it back and that prevents us from vectorizing the shuffle operation. There are probably more similar issues where this approach could

Hi Michael, >I have a case where InstCombine removes a store and your approach would be >valuable for me if the entire access to an aggregate could be restored. Yes, no problem and we could add the aggregate pointer to this new intrinsic and in my particular case I should ignore it, but I am looking now at "speculation_marker" metadata and I am still not sure how to implement it

On 09/13/2017 04:46 PM, Dinar Temirbulatov via llvm-dev wrote: > Hi Michael, >> I have a case where InstCombine removes a store and your approach would be >> valuable for me if the entire access to an aggregate could be restored. > Yes, no problem and we could add the aggregate pointer to this new > intrinsic and in my particular case I should ignore it, but I am > looking

Hi Michael, >Interesting approach but how do you handle more complex offsets, e.g., when the pointer is part of an aggregate? Only one offset does not seem enough to handle generic cases. Yes, correct, this a little bit changed example is not working. #include <x86intrin.h> __m256d vsht_d4_fold(const double* ptr, unsigned long long i) { __m256d foo = (__m256d){ ptr[i], ptr[i+1],

I'd like to propose that we add an attribute which expresses the notion that the specified value is /either/ null or dereferenceable up to a fixed size. (Note the xor.) Our current dereferenceable(n) attribute doesn't quite fit the bill, it implies that the pointer is non-null. Similarly, our nonnull attribute says nothing about dereferenceability. There are two syntax proposals

Hi, We are interesting in expanding some vector operations directly in the IR form as constants https://reviews.llvm.org/D33406, for example: _mm256_cmp_ps("any input", "any input", _CMP_TRUE_UQ) should produce -1, -1, -1, ... vector, but for some values for example "1.00 -nan" if FPU exceptions were enabled this operation triggers the exception. Here is the question:

This email is just to summarize a bit of digging I did last night into our attribute inference.  Unfortunately, I'm not going to have time to implement any of the gaps I noticed, but I figured someone else out there might be interested. *Missing Attributes* argmemonly - influences AA, particularly relevant for libraries which wrap build in functions which are annotated, but don't

Maybe we could list some of these as a GSoC project? Seems like a self-contained task that can be simple as desired and as hard as the student wants it to be. Nuno -----Original Message----- From: Philip Reames via llvm-dev Sent: Friday, February 16, 2018 6:48 PM To: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote:

Sure, but is anyone willing to mentor?  I don't have time.  I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote: > Yes, I agree with you this sounds like a great GSoC. > > On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Maybe we could list some of these as a GSoC project?

On 02/16/2018 10:29 AM, Philip Reames via llvm-dev wrote: > > This email is just to summarize a bit of digging I did last night into > our attribute inference.  Unfortunately, I'm not going to have time to > implement any of the gaps I noticed, but I figured someone else out > there might be interested. > > *Missing Attributes* > > argmemonly - influences AA,

Yes, I agree with you this sounds like a great GSoC. On Fri, Feb 16, 2018 at 3:42 PM, Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Maybe we could list some of these as a GSoC project? > Seems like a self-contained task that can be simple as desired and as hard > as the student wants it to be. > > Nuno > > -----Original Message----- From: Philip Reames

I can step in, if that's ok with you. Nuno -----Original Message----- From: Philip Reames Sent: Saturday, February 17, 2018 1:04 AM To: Davide Italiano ; Nuno Lopes Cc: llvm-dev Subject: Re: [llvm-dev] Missing attribute inference cases Sure, but is anyone willing to mentor? I don't have time. I can advise, but only infrequently. Philip On 02/16/2018 03:47 PM, Davide Italiano wrote:

SGTM On 02/17/2018 03:52 PM, Nuno Lopes wrote: > I can step in, if that's ok with you. > Nuno > > -----Original Message----- From: Philip Reames > Sent: Saturday, February 17, 2018 1:04 AM > To: Davide Italiano ; Nuno Lopes > Cc: llvm-dev > Subject: Re: [llvm-dev] Missing attribute inference cases > > Sure, but is anyone willing to mentor?  I don't have

LLVM's Attribute APIs need an overhaul. Current problems ================ First, testing for an attribute on an Argument is slow. llvm::AttributeSet::getAttributes(int) consumed 2% of cycles while optimizing llc during LTO. Our mid-level optimizations are constantly asking if a given argument has some attribute (nonnull, dereferencable, etc), and this is currently linear in the size of the

2017-04-05 18:30 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > Hi Piotr, > > On Mon, Apr 3, 2017 at 2:01 PM, Piotr Padlewski > <piotr.padlewski at gmail.com> wrote: > >> I don't see any way to model it right now in LLVM, but I see a one > simple > >> solution: > >> add extra information to the metadata nodes indicating that

2017-04-06 17:57 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>: > Hi Piotr, > > On April 6, 2017 at 2:36:53 AM, Piotr Padlewski > (piotr.padlewski at gmail.com) wrote: > > I disagree, I find it different than the patch you mentioned. We don't > have > > any problems with code like this: > > > > ptr = load i8*, i8** %ptrptr,

Hi all, I have a question about dereferenceable metadata on load instruction. I have a patch (https://reviews.llvm.org/D31539) for LICM that hoists loads with !invariant.group. The motivation example is devirtualization: struct A { virtual void foo(); }; int bar(); void indirect(A &a) { while(bar()) a.foo(); } With -O2 -fstrict-vtable-pointers we get: define void