hameeza ahmed via llvm-dev
2017-Jul-07 05:19 UTC
[llvm-dev] Error in v64i32 type in x86 backend
Thank You. On Fri, Jul 7, 2017 at 10:03 AM, Craig Topper <craig.topper at gmail.com> wrote:> Yes, that error is from instruction selection. I think your legalization > changes worked fine. > > ~Craig > > On Thu, Jul 6, 2017 at 8:21 PM, hameeza ahmed via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> also i further run the following command; >> llc -debug filer-knl_o3.ll >> >> and its output is attached here. by looking at the output can we say that >> legalization runs fine and the error is due to instruction selection/ >> pattern matching which is not yet implemented? >> >> so do i need to worry and try to correct it at this stage or should i >> move forward to implement instruction selection/ pattern matching? >> >> Please guide me. >> >> Thank You >> >> On Fri, Jul 7, 2017 at 8:00 AM, hameeza ahmed <hahmed2305 at gmail.com> >> wrote: >> >>> Thank You. well i have seen these links. but they dont cover the problem >>> that i have mentioned. actually i am doing all the things step by step. >>> >>> so i havent yet worked with instruction selection phase/ files. rather >>> before that i am trying to do legalization by allowing vector elements>16 >>> i.e 64xi32. here i have mainly worked with 2 files uptil now, i.e >>> registerinfo.td to define register class to be called in legalization. >>> and most importantly i am dealing with file X86ISelLowering.cpp. >>> >>> Now is there any relation in this and instruction selection. since >>> instruction selection comes after combine and legalize so i havent yet >>> worked on it. >>> >>> >>> Please correct me, I am stuck here. >>> >>> Thank You again >>> >>> On Fri, Jul 7, 2017 at 7:11 AM, Friedman, Eli <efriedma at codeaurora.org> >>> wrote: >>> >>>> Have you read http://llvm.org/docs/WritingAnLLVMBackend.html and >>>> http://llvm.org/docs/CodeGenerator.html ? >>>> http://llvm.org/docs/WritingAnLLVMBackend.html#instruction-selector >>>> describes how to define a store instruction. >>>> >>>> -Eli >>>> >>>> >>>> On 7/6/2017 6:51 PM, hameeza ahmed via llvm-dev wrote: >>>> >>>> Please correct me i m stuck at this point. >>>> >>>> On Jul 6, 2017 5:18 PM, "hameeza ahmed" <hahmed2305 at gmail.com> wrote: >>>> >>>> Hello, >>>> i am experimenting with the increase in register/ vector width to 64 >>>> elements of 32 bits instead of 16 in x86 backend. >>>> for eg. >>>> i have a loop with 65 iterations; >>>> if my IR generates v64i32 and 1 scalar, still the backend breaks the >>>> v64i32 into 4 v16i32. i want it to retain v64i32. like if there are 128 >>>> elements in loop then it should break it into 2 v64i32 instructions. >>>> >>>> in order to do this i have made necessary changes in >>>> X86ISelLowering.cpp. and rebuild llvm. then when i use the >>>> command -view-dag-combine2-dags i get the required output in graph but >>>> the following error on console: >>>> >>>> LLVM ERROR: Cannot select: t10: ch = store<ST256[bitcast ([65 x i32]* >>>> @a to <64 x i32>*)](align=16)(tbaa=<0x30c5438>)> t9, t7, t12, undef:i64 >>>> t7: v64i32 = add t6, t4 >>>> t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x >>>> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t14, >>>> undef:i64 >>>> t14: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* >>>> @c> 0 >>>> t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 >>>> t3: i64 = undef >>>> t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x >>>> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t16, >>>> undef:i64 >>>> t16: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* >>>> @b> 0 >>>> t15: i64 = TargetGlobalAddress<[65 x i32]* @b> 0 >>>> t3: i64 = undef >>>> t12: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* @a> 0 >>>> t11: i64 = TargetGlobalAddress<[65 x i32]* @a> 0 >>>> t3: i64 = undef >>>> In function: foo >>>> >>>> The dag after legalization is also attached here. >>>> >>>> the source is vector sum of 65 elements. >>>> >>>> >>>> Kindly correct me. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> >>>> -- >>>> Employee of Qualcomm Innovation Center, Inc. >>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>>> >>>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170707/772d053c/attachment.html>
hameeza ahmed via llvm-dev
2017-Jul-07 05:51 UTC
[llvm-dev] Error in v64i32 type in x86 backend
What is meant by folded instructions in LLVM? How they work? On Fri, Jul 7, 2017 at 10:19 AM, hameeza ahmed <hahmed2305 at gmail.com> wrote:> Thank You. > > On Fri, Jul 7, 2017 at 10:03 AM, Craig Topper <craig.topper at gmail.com> > wrote: > >> Yes, that error is from instruction selection. I think your legalization >> changes worked fine. >> >> ~Craig >> >> On Thu, Jul 6, 2017 at 8:21 PM, hameeza ahmed via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> also i further run the following command; >>> llc -debug filer-knl_o3.ll >>> >>> and its output is attached here. by looking at the output can we say >>> that legalization runs fine and the error is due to instruction selection/ >>> pattern matching which is not yet implemented? >>> >>> so do i need to worry and try to correct it at this stage or should i >>> move forward to implement instruction selection/ pattern matching? >>> >>> Please guide me. >>> >>> Thank You >>> >>> On Fri, Jul 7, 2017 at 8:00 AM, hameeza ahmed <hahmed2305 at gmail.com> >>> wrote: >>> >>>> Thank You. well i have seen these links. but they dont cover the >>>> problem that i have mentioned. actually i am doing all the things step by >>>> step. >>>> >>>> so i havent yet worked with instruction selection phase/ files. rather >>>> before that i am trying to do legalization by allowing vector elements>16 >>>> i.e 64xi32. here i have mainly worked with 2 files uptil now, i.e >>>> registerinfo.td to define register class to be called in legalization. >>>> and most importantly i am dealing with file X86ISelLowering.cpp. >>>> >>>> Now is there any relation in this and instruction selection. since >>>> instruction selection comes after combine and legalize so i havent yet >>>> worked on it. >>>> >>>> >>>> Please correct me, I am stuck here. >>>> >>>> Thank You again >>>> >>>> On Fri, Jul 7, 2017 at 7:11 AM, Friedman, Eli <efriedma at codeaurora.org> >>>> wrote: >>>> >>>>> Have you read http://llvm.org/docs/WritingAnLLVMBackend.html and >>>>> http://llvm.org/docs/CodeGenerator.html ? >>>>> http://llvm.org/docs/WritingAnLLVMBackend.html#instruction-selector >>>>> describes how to define a store instruction. >>>>> >>>>> -Eli >>>>> >>>>> >>>>> On 7/6/2017 6:51 PM, hameeza ahmed via llvm-dev wrote: >>>>> >>>>> Please correct me i m stuck at this point. >>>>> >>>>> On Jul 6, 2017 5:18 PM, "hameeza ahmed" <hahmed2305 at gmail.com> wrote: >>>>> >>>>> Hello, >>>>> i am experimenting with the increase in register/ vector width to 64 >>>>> elements of 32 bits instead of 16 in x86 backend. >>>>> for eg. >>>>> i have a loop with 65 iterations; >>>>> if my IR generates v64i32 and 1 scalar, still the backend breaks the >>>>> v64i32 into 4 v16i32. i want it to retain v64i32. like if there are 128 >>>>> elements in loop then it should break it into 2 v64i32 instructions. >>>>> >>>>> in order to do this i have made necessary changes in >>>>> X86ISelLowering.cpp. and rebuild llvm. then when i use the >>>>> command -view-dag-combine2-dags i get the required output in graph >>>>> but the following error on console: >>>>> >>>>> LLVM ERROR: Cannot select: t10: ch = store<ST256[bitcast ([65 x i32]* >>>>> @a to <64 x i32>*)](align=16)(tbaa=<0x30c5438>)> t9, t7, t12, >>>>> undef:i64 >>>>> t7: v64i32 = add t6, t4 >>>>> t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x >>>>> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t14, >>>>> undef:i64 >>>>> t14: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* >>>>> @c> 0 >>>>> t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 >>>>> t3: i64 = undef >>>>> t4: v64i32,ch = load<LD256[bitcast ([65 x i32]* @b to <64 x >>>>> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> t0, t16, >>>>> undef:i64 >>>>> t16: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* >>>>> @b> 0 >>>>> t15: i64 = TargetGlobalAddress<[65 x i32]* @b> 0 >>>>> t3: i64 = undef >>>>> t12: i64 = X86ISD::Wrapper TargetGlobalAddress:i64<[65 x i32]* @a> 0 >>>>> t11: i64 = TargetGlobalAddress<[65 x i32]* @a> 0 >>>>> t3: i64 = undef >>>>> In function: foo >>>>> >>>>> The dag after legalization is also attached here. >>>>> >>>>> the source is vector sum of 65 elements. >>>>> >>>>> >>>>> Kindly correct me. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>>> >>>>> -- >>>>> Employee of Qualcomm Innovation Center, Inc. >>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170707/c932472b/attachment.html>
Friedman, Eli via llvm-dev
2017-Jul-07 17:59 UTC
[llvm-dev] Error in v64i32 type in x86 backend
The word "fold" is used all over LLVM. It generally refers to transformations which delete an instruction. If you're asking about http://llvm.org/docs/CodeGenerator.html#instruction-folding , it just means an instruction which was produced by the "instruction folding" transform; there isn't anything special about the instruction itself. -Eli On 7/6/2017 10:51 PM, hameeza ahmed wrote:> What is meant by folded instructions in LLVM? > How they work? > > On Fri, Jul 7, 2017 at 10:19 AM, hameeza ahmed <hahmed2305 at gmail.com > <mailto:hahmed2305 at gmail.com>> wrote: > > Thank You. > > On Fri, Jul 7, 2017 at 10:03 AM, Craig Topper > <craig.topper at gmail.com <mailto:craig.topper at gmail.com>> wrote: > > Yes, that error is from instruction selection. I think your > legalization changes worked fine. > > ~Craig > > On Thu, Jul 6, 2017 at 8:21 PM, hameeza ahmed via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > also i further run the following command; > llc -debug filer-knl_o3.ll > > and its output is attached here. by looking at the output > can we say that legalization runs fine and the error is > due to instruction selection/ pattern matching which is > not yet implemented? > > so do i need to worry and try to correct it at this stage > or should i move forward to implement instruction > selection/ pattern matching? > > Please guide me. > > Thank You > > On Fri, Jul 7, 2017 at 8:00 AM, hameeza ahmed > <hahmed2305 at gmail.com <mailto:hahmed2305 at gmail.com>> wrote: > > Thank You. well i have seen these links. but they dont > cover the problem that i have mentioned. actually i am > doing all the things step by step. > > so i havent yet worked with instruction selection > phase/ files. rather before that i am trying to do > legalization by allowing vector elements>16 i.e > 64xi32. here i have mainly worked with 2 files uptil > now, i.e registerinfo.td <http://registerinfo.td> to > define register class to be called in legalization. > and most importantly i am dealing with file > X86ISelLowering.cpp. > > Now is there any relation in this and instruction > selection. since instruction selection comes after > combine and legalize so i havent yet worked on it. > > > Please correct me, I am stuck here. > > Thank You again > > On Fri, Jul 7, 2017 at 7:11 AM, Friedman, Eli > <efriedma at codeaurora.org > <mailto:efriedma at codeaurora.org>> wrote: > > Have you read > http://llvm.org/docs/WritingAnLLVMBackend.html > <http://llvm.org/docs/WritingAnLLVMBackend.html> > and http://llvm.org/docs/CodeGenerator.html > <http://llvm.org/docs/CodeGenerator.html> ? > http://llvm.org/docs/WritingAnLLVMBackend.html#instruction-selector > <http://llvm.org/docs/WritingAnLLVMBackend.html#instruction-selector> > describes how to define a store instruction. > > -Eli > > > On 7/6/2017 6:51 PM, hameeza ahmed via llvm-dev wrote: >> Please correct me i m stuck at this point. >> >> On Jul 6, 2017 5:18 PM, "hameeza ahmed" >> <hahmed2305 at gmail.com >> <mailto:hahmed2305 at gmail.com>> wrote: >> >> Hello, >> i am experimenting with the increase in >> register/ vector width to 64 elements of 32 >> bits instead of 16 in x86 backend. >> for eg. >> i have a loop with 65 iterations; >> if my IR generates v64i32 and 1 scalar, still >> the backend breaks the v64i32 into 4 v16i32. >> i want it to retain v64i32. like if there are >> 128 elements in loop then it should break it >> into 2 v64i32 instructions. >> >> in order to do this i have made necessary >> changes in X86ISelLowering.cpp. and rebuild >> llvm. then when i use the >> command -view-dag-combine2-dags i get the >> required output in graph but the following >> error on console: >> >> LLVM ERROR: Cannot select: t10: ch >> store<ST256[bitcast ([65 x i32]* @a to <64 x >> i32>*)](align=16)(tbaa=<0x30c5438>)> t9, t7, >> t12, undef:i64 >> t7: v64i32 = add t6, t4 >> t6: v64i32,ch = load<LD256[bitcast ([65 x >> i32]* @c to <64 x >> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> >> t0, t14, undef:i64 >> t14: i64 = X86ISD::Wrapper >> TargetGlobalAddress:i64<[65 x i32]* @c> 0 >> t13: i64 = TargetGlobalAddress<[65 x i32]* @c> 0 >> t3: i64 = undef >> t4: v64i32,ch = load<LD256[bitcast ([65 x >> i32]* @b to <64 x >> i32>*)](align=16)(tbaa=<0x30c5438>)(dereferenceable)> >> t0, t16, undef:i64 >> t16: i64 = X86ISD::Wrapper >> TargetGlobalAddress:i64<[65 x i32]* @b> 0 >> t15: i64 = TargetGlobalAddress<[65 x i32]* @b> 0 >> t3: i64 = undef >> t12: i64 = X86ISD::Wrapper >> TargetGlobalAddress:i64<[65 x i32]* @a> 0 >> t11: i64 = TargetGlobalAddress<[65 x >> i32]* @a> 0 >> t3: i64 = undef >> In function: foo >> >> The dag after legalization is also attached here. >> >> the source is vector sum of 65 elements. >> >> >> Kindly correct me. >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > >-- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170707/86d9a3e8/attachment.html>