search for: llvm_anyptr_ty

...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 be applied. I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, indicating that for particular pointer let's call it %ptr we observed maximum possible offset at which there was reference by its type in a function. After InstCombine deleted the load operation, it could be restored in SLPVectorizer and we could restore chains...

...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 be applied. > I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, > indicating that for particular pointer let's call it %ptr we observed > maximum possible offset at which there was reference by its type in a > function. After InstCombine deleted the load operation, it could be > restored in SLPVectorizer and we...

...ask) 6 types x 3 vector sizes = 18 names for one operation I propose to remove name mangling from these intrinsics: %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x i32>%passthru, i32 4, <16 x i1> %mask) def int_masked_load : Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, NoNameMangling]>; // new property It will significantly simplify reading and manual writing. What do you think? Thank you. - Elena ---------------------------------------------------------------...

...n its arguments, but when calling this intrinsic, if the pointer is not in the generic address space (ie AddrSpace 0), an error occurs ("bad signature"). > > How can I specify the address space in the intrinsic definition ? > Thank you. Julien, If the type of your parameter is llvm_anyptr_ty it should just work with non-default address spaces. I don't immediately see anything actually using this type though, so there may be a bug somewhere. I'd verify that you have defined the intrinsic and then possibly post more information to the list with more details or a test case if...

...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 be applied. >>> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, >>> indicating that for particular pointer let's call it %ptr we observed >>> maximum possible offset at which there was reference by its type in a >>> function. After InstCombine deleted the load operation, it could be >>> r...

I would like to use intrinsic with different address space. I defined an intrinsic (used to represent à specific instruction of my target) with a pointer in its arguments, but when calling this intrinsic, if the pointer is not in the generic address space (ie AddrSpace 0), an error occurs ("bad signature"). How can I specify the address space in the intrinsic definition ? Thank you.

...= call i32 @delta(i32 %tmp15, i32 %tmp16, i32 %tmp18, i32 %tmp20) ... It is compiled by clang 2.9. This BB is an end block in a function. Intrinsic function llvm.guard.load.p0i32 is defined as follows: let Properties = [IntrNoMem, NoCapture<0>] in { def int_guard_load : Intrinsic<[llvm_anyptr_ty], [LLVMMatchType<0>]> } Thanks a lot. Bin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111006/894fd8b5/attachment.html>

...ase 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 be applied. >>>> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, >>>> indicating that for particular pointer let's call it %ptr we observed >>>> maximum possible offset at which there was reference by its type in a >>>> function. After InstCombine deleted the load operation, it could be &g...

...> %tmp20) >>   ... >> >> It is compiled by clang 2.9. This BB is an end block in a function. >> Intrinsic function llvm.guard.load.p0i32 is defined as follows: >> let Properties = [IntrNoMem, NoCapture<0>] in { >>     def int_guard_load   : Intrinsic<[llvm_anyptr_ty], [LLVMMatchType<0>]> >> } >> >> Thanks a lot. > > IntrNoMem means that your intrinsic doesn't access memory... I don't > think that is what you want. Well, either that or the NoCapture marking is wrong. What exactly is your int_guard_load supposed to d...

...t;>>>> 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 be applied. >>>>> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, >>>>> indicating that for particular pointer let's call it %ptr we observed >>>>> maximum possible offset at which there was reference by its type in a >>>>> function. After InstCombine deleted the load operation, it...

...t; I propose to remove name mangling from these intrinsics: >>> %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x >>> i32>%passthru, i32 4, <16 x i1> %mask) >>> >>> def int_masked_load : >>> Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, >>> llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, >>> NoNameMangling]>; >>> // new property >>> >>> It will significantly simplify reading and manual writing. >>> What do you think? >> >> We already ha...

...es = 18 names for one operation > > I propose to remove name mangling from these intrinsics: > %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x > i32>%passthru, i32 4, <16 x i1> %mask) > > def int_masked_load : > Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, > llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, NoNameMangling]>; > // new property > > It will significantly simplify reading and manual writing. > What do you think? We already have this kind of situation for @llvm.memcpy and friends, and while it...

...%tmp16, i32 %tmp18, i32 > %tmp20) >   ... > > It is compiled by clang 2.9. This BB is an end block in a function. > Intrinsic function llvm.guard.load.p0i32 is defined as follows: > let Properties = [IntrNoMem, NoCapture<0>] in { >     def int_guard_load   : Intrinsic<[llvm_anyptr_ty], [LLVMMatchType<0>]> > } > > Thanks a lot. IntrNoMem means that your intrinsic doesn't access memory... I don't think that is what you want. -Eli

...t;> 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 be applied. >>>>>> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, >>>>>> indicating that for particular pointer let's call it %ptr we observed >>>>>> maximum possible offset at which there was reference by its type in a >>>>>> function. After InstCombine deleted the load o...

..... > >> > >> It is compiled by clang 2.9. This BB is an end block in a function. > >> Intrinsic function llvm.guard.load.p0i32 is defined as follows: > >> let Properties = [IntrNoMem, NoCapture<0>] in { > >> def int_guard_load : Intrinsic<[llvm_anyptr_ty], > [LLVMMatchType<0>]> > >> } > >> > >> Thanks a lot. > > > > IntrNoMem means that your intrinsic doesn't access memory... I don't > > think that is what you want. > > Well, either that or the NoCapture marking is wrong. What...

...>> >> It is compiled by clang 2.9. This BB is an end block in a function. >> >> Intrinsic function llvm.guard.load.p0i32 is defined as follows: >> >> let Properties = [IntrNoMem, NoCapture<0>] in { >> >>     def int_guard_load   : Intrinsic<[llvm_anyptr_ty], >> >> [LLVMMatchType<0>]> >> >> } >> >> >> >> Thanks a lot. >> > >> > IntrNoMem means that your intrinsic doesn't access memory... I don't >> > think that is what you want. >> >> Well, either t...

...le to read old .bc and .ll files that use the previous form of the intrinsic. -Chris > > This patch updates the type of the second parameter of memset in > Intrinsics.td, from llvm_i8_ty, to llvm_anyint_ty: > > def int_memset : Intrinsic<[], > - [llvm_anyptr_ty, llvm_i8_ty, llvm_anyint_ty, > + [llvm_anyptr_ty, llvm_anyint_ty, llvm_anyint_ty, > llvm_i32_ty, llvm_i1_ty], > > IRBuilder.cpp and LangRef.html is updated accordingly. > > To use the intrinsic, the declaration, > >...

Masked load/store are overloaded intrinsics, the only generic type is the type of the value being loaded/stored. The signature of the intrinsic is generated based on this type. The type of the pointer argument is generated as a pointer to the return type with default addrspace. E.g.: declare <8 x i32> @llvm.masked.load.v8i32(<8 x i32>*, i32, <8 x i1>, <8 x i32>) The

On Fri, Mar 6, 2009 at 7:34 PM, Tanya M. Lattner <tonic at nondot.org> wrote: > > This should be fixed now. I verified it with 3.4.6 on a x86 linux box. > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090302/074769.html > > I think most of our nightly testers are using gcc4. Works for me, thanks. Still a bit puzzled why this didn't break under gcc4,