search for: d17270

...er with underlying type being a data type. In this case the signature of the intrinsic above would be: declare <8 x i32> @llvm.masked.load.v8i32.p1v8i32(<8 x i32> addrspace(1)*, i32, <8 x i1>, <8 x i32>) Corresponding patch is posted on phabricator: http://reviews.llvm.org/D17270 Any comments, objections or alternatives? Artur -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160215/3bd2328c/attachment.html>

..., Ayal, arsenm, pjcoup. delena added a subscriber: llvm-commits. delena set the repository for this revision to rL LLVM. This is an alternative proposal for supporting address space in intrinsics. It's applicable for any intrinsic, not only masked-load-store. Related to http://reviews.llvm.org/D17270 I this proposal I add non-zero address space suffix to intrinsic name. The original name looks like @llvm.xxx.xxx The same name with address space 1 : @llvm.xxx.xxx.a_1 (I did not update documentation. I'll do this if the proposed change looks reasonable for reviewers ). Repository: rL LL...

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 addressing > a correctness problem; that has to overrule stylistic concerns. We > are seeing failures in our nightly tests due to this issue on an > ongoing basis, and I'...

...dules and eventually map isomorphic types to a single type. So isomorphic types get their original names. Although in some cases it causes problems. Initially I came across the problem with my recent change which added an overloaded type to the masked load/store intrinsics (http://reviews.llvm.org/D17270). The discrepancy between the name and the signature triggers auto-upgrade bit from my patch converting an incorrect mangling to the correct one. But later after remapping of isomorphic types when we return to the original type name this “updated" intrinsic name become invalid. Another way to...

...isomorphic types to a single type. So isomorphic types get > their original names. Although in some cases it causes problems. > > Initially I came across the problem with my recent change which added an > overloaded type to the masked load/store intrinsics > (http://reviews.llvm.org/D17270). The discrepancy between the name and the > signature triggers auto-upgrade bit from my patch converting an incorrect > mangling to the correct one. But later after remapping of isomorphic types > when we return to the original type name this “updated" intrinsic name > become inva...

...lena added a subscriber: llvm-commits. > delena set the repository for this revision to rL LLVM. > > This is an alternative proposal for supporting address space in intrinsics. It's applicable for any intrinsic, not only masked-load-store. > Related to > http://reviews.llvm.org/D17270 > > > I this proposal I add non-zero address space suffix to intrinsic name. The original name looks like > @llvm.xxx.xxx > The same name with address space 1 : > @llvm.xxx.xxx.a_1 > > (I did not update documentation. I'll do this if the proposed change looks reasonab...

...ype. So isomorphic > types get > > their original names. Although in some cases it causes problems. > > > > Initially I came across the problem with my recent change which added an > > overloaded type to the masked load/store intrinsics > > (http://reviews.llvm.org/D17270). The discrepancy between the name > and the > > signature triggers auto-upgrade bit from my patch converting an > incorrect > > mangling to the correct one. But later after remapping of isomorphic > types > > when we return to the original type name this “updated&quot...