Yes, the target does not have 64-bit GPRs. But it still needs to support 64-bit address space. Cheers, Iftekhar On Tue, Jul 8, 2014 at 1:19 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > From: "Iftekhar Chowdhury" <iftekhar.hc at gmail.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Tuesday, July 8, 2014 1:06:44 PM > > Subject: [LLVMdev] Selection DAG node for 64-bit load > > > > > > > > > > > > Hi Fellow LLVM Experts, > > > > Currently, Selection DAG node for load seems to expect a 32-bit base > > and an offset. Is it possible to extend load node definition to 2 > > 32-bit bases and an offset? Two 32-bit bases are supposed to > > represent one 64-bit address. > > > > > > I don't understand why you're suggesting this? Does your target have a > 64-bit address space but no 64-bit GPRs? > > -Hal > > > > > Any suggestions, comments are much appreciated. > > > > > > > > Regards, > > > > Iftekhar > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140708/1e31e737/attachment.html>
Hi Do the two 32-bit bases need to be stored in consecutive registers? If so, you could still use the 64-bit loads and then use REQ_SEQUENCE to create a pair of 32-bit registers. -Tom On Tue, Jul 08, 2014 at 01:46:30PM -0700, Iftekhar Chowdhury wrote:> Yes, the target does not have 64-bit GPRs. But it still needs to support > 64-bit address space. > > Cheers, > Iftekhar > > > On Tue, Jul 8, 2014 at 1:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ----- Original Message ----- > > > From: "Iftekhar Chowdhury" <iftekhar.hc at gmail.com> > > > To: llvmdev at cs.uiuc.edu > > > Sent: Tuesday, July 8, 2014 1:06:44 PM > > > Subject: [LLVMdev] Selection DAG node for 64-bit load > > > > > > > > > > > > > > > > > > Hi Fellow LLVM Experts, > > > > > > Currently, Selection DAG node for load seems to expect a 32-bit base > > > and an offset. Is it possible to extend load node definition to 2 > > > 32-bit bases and an offset? Two 32-bit bases are supposed to > > > represent one 64-bit address. > > > > > > > > > > I don't understand why you're suggesting this? Does your target have a > > 64-bit address space but no 64-bit GPRs? > > > > -Hal > > > > > > > > Any suggestions, comments are much appreciated. > > > > > > > > > > > > Regards, > > > > > > Iftekhar > > > _______________________________________________ > > > LLVM Developers mailing list > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > >> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Tom, Thanks for getting back to me. Let me elaborate on my problem a bit. Currently, Selection DAG generates the following for stack load / store when needed: LOAD <FrameIndex #0>, 0, .... ; 0 = offset I would like to change the above to: LOAD <FrameIndex #0>, %Dummy_GPR, 0, .... The Dummy_GPR is used for 32-bit pointers, which will be ignored by later passes. The idea is to have a single instruction format for both 32-bit and 64-bit load / store. I have already modifed TD to reflect instruction format changes. I am currently hitting an assertion in InstrEmitter::EmitMachineNode due to mismatch between TD definition and SDNode definition. I'm not quite sure how to go about changing SDNode definition for LOAD to reflect TD changes. Any suggestions are much appreciated. Regards, Iftekhar On Tue, Jul 8, 2014 at 2:10 PM, Tom Stellard <tom at stellard.net> wrote:> Hi > > Do the two 32-bit bases need to be stored in consecutive registers? If > so, you could still use the 64-bit loads and then use REQ_SEQUENCE to > create > a pair of 32-bit registers. > > -Tom > > On Tue, Jul 08, 2014 at 01:46:30PM -0700, Iftekhar Chowdhury wrote: > > Yes, the target does not have 64-bit GPRs. But it still needs to support > > 64-bit address space. > > > > Cheers, > > Iftekhar > > > > > > On Tue, Jul 8, 2014 at 1:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > > ----- Original Message ----- > > > > From: "Iftekhar Chowdhury" <iftekhar.hc at gmail.com> > > > > To: llvmdev at cs.uiuc.edu > > > > Sent: Tuesday, July 8, 2014 1:06:44 PM > > > > Subject: [LLVMdev] Selection DAG node for 64-bit load > > > > > > > > > > > > > > > > > > > > > > > > Hi Fellow LLVM Experts, > > > > > > > > Currently, Selection DAG node for load seems to expect a 32-bit base > > > > and an offset. Is it possible to extend load node definition to 2 > > > > 32-bit bases and an offset? Two 32-bit bases are supposed to > > > > represent one 64-bit address. > > > > > > > > > > > > > > I don't understand why you're suggesting this? Does your target have a > > > 64-bit address space but no 64-bit GPRs? > > > > > > -Hal > > > > > > > > > > > Any suggestions, comments are much appreciated. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Iftekhar > > > > _______________________________________________ > > > > LLVM Developers mailing list > > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > -- > > > Hal Finkel > > > Assistant Computational Scientist > > > Leadership Computing Facility > > > Argonne National Laboratory > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140708/b4fea4ce/attachment.html>