similar to: Masked intrinsics and non-default address spaces

This probably needs broader discussion. We have an existing naming mechanism for polymorphic intrinsics; Elena is proposing a new one to avoid making the names for various load/store intrinsics particularly ugly. My personal take: 1) I like the cleaner naming scheme. 2) I'm not sure the additional complexity is worth it. (Not specific to the particular implementation proposed here.) 3) I

In the current mangling scheme for overloaded intrinsics we include overloaded type names in the intrinsic name. For example: %struct.foobar = type { i32 } declare <4 x %struct.foobar*> @llvm.masked.load.v4p0struct.foobar(<4 x %struct.foobar*>*, i32, <4 x i1>, <4 x %struct.foobar*>) Verifier checks that an overloaded intrinsic name matches with its signature. When

My gut feeling is that it’s not worth it. When we move from typed to untyped pointers, we’re going to change the mangling from something like p200i8 to just p200, which is already quite a bit cleaner, and actually looks cleaner to me than the version proposed in this patch. David > On 24 Feb 2016, at 17:28, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This

Per my previous email, I have just signed off on Artur's original patch. Philip On 03/02/2016 11:21 AM, Philip Reames via llvm-dev wrote: > Elena, > > I'd like to propose that we move forward withArtur's original patch > <http://reviews.llvm.org/D17270> and separate the discussion of how we > might change our intrinsic naming scheme. Artur's patch is

On 18 April 2016 at 19:22, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 04/18/2016 09:45 AM, Artur Pilipenko via llvm-dev wrote: > > In the current mangling scheme for overloaded intrinsics we include > overloaded type names in the intrinsic name. For example: > > %struct.foobar = type { i32 } > declare <4 x %struct.foobar*>

Ok, thanks. Are there any plans to reintroduce it on the IR level? I'm not confident this is strictly necessary, but in some cases not having load widening ends up really bad. Like in the case where vectorizer tries to do something about it: https://godbolt.org/z/60RuEw https://bugs.llvm.org/show_bug.cgi?id=42708 At the current state I'm forced to use memset() to express uint64 load from

If we do load combining at the IR level, one thing we'll need to give some thought to is atomicity.  Combining two atomic loads into a wider (legal) atomic load is not a reversible transformation given our current specification. I've been thinking about a concept I've been tentatively calling "element wise atomicity" which would make this a reversible transform by

Hi, Can I ask what is the status of load widening. It seems there is no load widening on IR at all. // Paweł On Wed, Oct 5, 2016 at 1:49 PM Artur Pilipenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Philip and I talked about this is person. Given the fact that load > widening in presence of atomics is irreversible transformation we agreed > that we don't want to do

One of the arguments for doing this earlier is inline cost perception of the original pattern. Reading i32/i64 by bytes look much more expensive than it is and can prevent inlining of interesting function. Inhibiting other optimizations concern can be addressed by careful selection of the pattern we’d like to match. I limit the transformation to the case when all the individual have no uses other

Yes, I'm running all the existing passes that I know how to run. I didn't know they returned change-made. Thanks! On Mon, Dec 21, 2015 at 12:36 PM, Artur Pilipenko < apilipenko at azulsystems.com> wrote: > Are you going to run some of the existing passes? Why can’t you just use > the returned change-made value from the passes? > > Artur > > > On 20 Dec 2015, at

> On Oct 26, 2014, at 8:22 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> From: "Elena Demikhovsky" <elena.demikhovsky at intel.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Sunday, October 26, 2014 10:17:49 AM >> Subject: RE: [LLVMdev] Masked vector

On 04/18/2016 10:52 AM, Ahmed Bougacha via llvm-dev wrote: > On Mon, Apr 18, 2016 at 9:45 AM, Artur Pilipenko via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > In the current mangling scheme for overloaded intrinsics we include > > overloaded type names in the intrinsic name. For example: > > > > %struct.foobar =

> On 29 Sep 2016, at 21:01, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Artur, > > Artur Pilipenko wrote: > > > BTW, do we really need to emit an atomic load if all the individual > > components are bytes? > > Depends -- do you mean at the at the hardware level or at the IR > level? > > If you mean at the IR level, then I

Hi Sanjay, Some time ago you implemented a sext(add_nsw(x, C)) --> add(sext(x), C_sext) transformation in X86ISelLowering https://reviews.llvm.org/D13757 Is there any reason why this transformation is limited to sexts and doesn’t support zexts? Thanks, Artur -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, On 13 Jul 2015, at 15:59, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: ----- Original Message ----- From: "Artur Pilipenko" <apilipenko at azulsystems.com<mailto:apilipenko at azulsystems.com>> To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Cc: "Hal Finkel" <hfinkel at anl.gov<mailto:hfinkel at

> On 29 Sep 2016, at 03:23, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Artur, > > Artur Pilipenko via llvm-dev wrote: > > One of the arguments for doing this earlier is inline cost > > perception of the original pattern. Reading i32/i64 by bytes look much > > more expensive than it is and can prevent inlining of interesting > >

I agree. There’s implementation-defined behavior on the conversion of (arg*58) to int, but that shouldn’t be at issue here. The transform of (float)x + 1 => (float)(x + 1) is bogus. > On Mar 20, 2017, at 10:41 AM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Looks broken to me; I don't think there's UB in the original program. > > The fold in

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Other

> On Jul 14, 2015, at 4:48 PM, Reid Kleckner <rnk at google.com> wrote: > > This sounds more like a use case for metadata. Can we attach metadata to function arguments, or does that not work currently? We can’t, no. I have an out of tree patch which allows metadata in AttributeSets. This would also potentially also work here. However, depending on the number of unique

I'm looking at the bug (https://llvm.org/bugs/show_bug.cgi?id=31181) which was triggered by my change to make CVP mark adds as no wrap (https://reviews.llvm.org/rL278220) and I'd like to have some broader discussion of the problem. In this bug CVP correctly marks an add as nuw basing on the loop latch check, but later loop rotation pass moves the add to a point before the check. In the new