John Criswell
2011-Jan-20 18:31 UTC
[LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
On 1/20/11 12:27 PM, Venkatraman Govindaraju wrote: Just out of curiosity, have either of you considered writing an LLVM transform that simply replaces these call instructions with inline assembly code that does what you want? If that works, it seems much simpler than modifying/enhancing the code generator. -- John T.> I have similar requirements for my project. This is what I do. > > 1. Add a new intrinsic function to LLVM that corresponds to > "functions with particular type of function names". > The steps to create intrinsic function is documented in > http://llvm.org/docs/ExtendingLLVM.html#intrinsic. > 2. Create a lowering pass that lowers "functions with particular > type" ( eg. p0, p1) to the intrinsic. > 3. Create a instruction pattern in SparcInstrInfo.td that matches > the intrinsic. > From the arguments to the intrinsic function, encode the > "<number>" and output a "sethi" instruction. > > Thanks, > Venkatraman > > > On Tue, Jan 18, 2011 at 11:18 PM, Raghu Prabhakar<raghu at cs.ucla.edu> wrote: >> Hello all, >> >> I am trying to modify the Sparc backend to do something for my team's project, to do the following. >> >> Whenever the backend encounters a call to one particular type of function names (functions like p0(), p1()..etc), I want the backend to generate a "sethi %g0,<number>", and NOT a "call p0, call p1..." instruction. However, the backend should work as usual for any other function name. >> >> Now I figured that there are two ways to do this : >> 1) Modifying the "SparcISelLowering.cpp" to emit a special SDNode (with a special opcode that I have introduced into SPISD namespace) whenever it finds a "call @p0" in the LowerCall function. This node should have an entry in the "SparcInstrInfo.td" file. >> >> 2) No modifications to the Lowering phase. However, the pattern corresponding to the "sethi" instruction must be modified/new pattern added which corresponds to "call p0" kind of selectionDAG nodes. >> >> In either case, I am a bit confused about how tblgen's pattern representation scheme works. One more issue is that the destination register of "sethi %g0,<NUM>" HAS to be %g0 (which makes it a no-op on an actual sparc machine..I'm using a simulator), and<NUM> depends on p0 and its operands. There are ways where the certain registers required can be hard-assigned during instruction selection itself, but I'm unsure as to how to do that. Am I looking at the right set of files? Is there a better way to accomplish what I'm trying to do? >> >> I'm relatively new to LLVM, so I have some trouble freely navigating through the source in spite of being heavily documented. >> >> Any suggestions is of great help. >> >> Thanks. >> Raghu. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Venkatraman Govindaraju
2011-Jan-20 19:01 UTC
[LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
For my case, I can't replace these call instructions with inline assembly code because I need to encode the registers into the "number". For instance, if the call instruction is %result = call i32 @foo(i32 %a) and the result is assigned to register %l0 and the variable "a" to register %l1, then I encode all foo, %l0 and %l1 and generate a sethi instruction. thanks, Venkatraman On Thu, Jan 20, 2011 at 12:31 PM, John Criswell <criswell at illinois.edu> wrote:> On 1/20/11 12:27 PM, Venkatraman Govindaraju wrote: > > Just out of curiosity, have either of you considered writing an LLVM > transform that simply replaces these call instructions with inline assembly > code that does what you want? If that works, it seems much simpler than > modifying/enhancing the code generator. > > -- John T. > >> I have similar requirements for my project. This is what I do. >> >> 1. Add a new intrinsic function to LLVM that corresponds to >> "functions with particular type of function names". >> The steps to create intrinsic function is documented in >> http://llvm.org/docs/ExtendingLLVM.html#intrinsic. >> 2. Create a lowering pass that lowers "functions with particular >> type" ( eg. p0, p1) to the intrinsic. >> 3. Create a instruction pattern in SparcInstrInfo.td that matches >> the intrinsic. >> From the arguments to the intrinsic function, encode the >> "<number>" and output a "sethi" instruction. >> >> Thanks, >> Venkatraman >> >> >> On Tue, Jan 18, 2011 at 11:18 PM, Raghu Prabhakar<raghu at cs.ucla.edu> >> wrote: >>> >>> Hello all, >>> >>> I am trying to modify the Sparc backend to do something for my team's >>> project, to do the following. >>> >>> Whenever the backend encounters a call to one particular type of function >>> names (functions like p0(), p1()..etc), I want the backend to generate a >>> "sethi %g0,<number>", and NOT a "call p0, call p1..." instruction. However, >>> the backend should work as usual for any other function name. >>> >>> Now I figured that there are two ways to do this : >>> 1) Modifying the "SparcISelLowering.cpp" to emit a special SDNode (with a >>> special opcode that I have introduced into SPISD namespace) whenever it >>> finds a "call @p0" in the LowerCall function. This node should have an entry >>> in the "SparcInstrInfo.td" file. >>> >>> 2) No modifications to the Lowering phase. However, the pattern >>> corresponding to the "sethi" instruction must be modified/new pattern added >>> which corresponds to "call p0" kind of selectionDAG nodes. >>> >>> In either case, I am a bit confused about how tblgen's pattern >>> representation scheme works. One more issue is that the destination register >>> of "sethi %g0,<NUM>" HAS to be %g0 (which makes it a no-op on an actual >>> sparc machine..I'm using a simulator), and<NUM> depends on p0 and its >>> operands. There are ways where the certain registers required can be >>> hard-assigned during instruction selection itself, but I'm unsure as to how >>> to do that. Am I looking at the right set of files? Is there a better way to >>> accomplish what I'm trying to do? >>> >>> I'm relatively new to LLVM, so I have some trouble freely navigating >>> through the source in spite of being heavily documented. >>> >>> Any suggestions is of great help. >>> >>> Thanks. >>> Raghu. >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Raghu Prabhakar
2011-Jan-20 20:59 UTC
[LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
I face the same problem - The function name and registers used must be encoded into the <number>. Adding an intrinsic function looks like a neat way to do things. In my current approach, I have done the following : 1) I have added a new instruction in the "SPISD" namespace, and modified the "SparcISelLowering.cpp" to emit TRAPINST into the selectionDAG whenever a "call @p0". This part is working fine. 2) I want to edit the SparcInstrInfo.td file to emit a "sethi %g0,<number>" whenever it tries to pattern match the SPISD::TRAPINST node. I am, however, stuck in this step. My instruction selector is failing to come up with a match. I looked in the "SparcGenInstrNames.inc" file, and I did not find "TRAPINST" there. Is there something fundamentally wrong that I'm doing here while adding a pattern? Thanks for the help ! Raghu. For my case, I can't replace these call instructions with inline assembly code because I need to encode the registers into the "number". For instance, if the call instruction is %result = call i32 @foo(i32 %a) and the result is assigned to register %l0 and the variable "a" to register %l1, then I encode all foo, %l0 and %l1 and generate a sethi instruction. On Thu, Jan 20, 2011 at 12:31 PM, John Criswell <criswell at illinois.edu> wrote:> On 1/20/11 12:27 PM, Venkatraman Govindaraju wrote: > > Just out of curiosity, have either of you considered writing an LLVM > transform that simply replaces these call instructions with inline assembly > code that does what you want? If that works, it seems much simpler than > modifying/enhancing the code generator. > > -- John T. > >> I have similar requirements for my project. This is what I do. >> >> 1. Add a new intrinsic function to LLVM that corresponds to >> "functions with particular type of function names". >> The steps to create intrinsic function is documented in >> http://llvm.org/docs/ExtendingLLVM.html#intrinsic. >> 2. Create a lowering pass that lowers "functions with particular >> type" ( eg. p0, p1) to the intrinsic. >> 3. Create a instruction pattern in SparcInstrInfo.td that matches >> the intrinsic. >> From the arguments to the intrinsic function, encode the >> "<number>" and output a "sethi" instruction. >> >> Thanks, >> Venkatraman >> >> >> On Tue, Jan 18, 2011 at 11:18 PM, Raghu Prabhakar<raghu at cs.ucla.edu> >> wrote: >>> >>> Hello all, >>> >>> I am trying to modify the Sparc backend to do something for my team's >>> project, to do the following. >>> >>> Whenever the backend encounters a call to one particular type of function >>> names (functions like p0(), p1()..etc), I want the backend to generate a >>> "sethi %g0,<number>", and NOT a "call p0, call p1..." instruction. However, >>> the backend should work as usual for any other function name. >>> >>> Now I figured that there are two ways to do this : >>> 1) Modifying the "SparcISelLowering.cpp" to emit a special SDNode (with a >>> special opcode that I have introduced into SPISD namespace) whenever it >>> finds a "call @p0" in the LowerCall function. This node should have an entry >>> in the "SparcInstrInfo.td" file. >>> >>> 2) No modifications to the Lowering phase. However, the pattern >>> corresponding to the "sethi" instruction must be modified/new pattern added >>> which corresponds to "call p0" kind of selectionDAG nodes. >>> >>> In either case, I am a bit confused about how tblgen's pattern >>> representation scheme works. One more issue is that the destination register >>> of "sethi %g0,<NUM>" HAS to be %g0 (which makes it a no-op on an actual >>> sparc machine..I'm using a simulator), and<NUM> depends on p0 and its >>> operands. There are ways where the certain registers required can be >>> hard-assigned during instruction selection itself, but I'm unsure as to how >>> to do that. Am I looking at the right set of files? Is there a better way to >>> accomplish what I'm trying to do? >>> >>> I'm relatively new to LLVM, so I have some trouble freely navigating >>> through the source in spite of being heavily documented. >>> >>> Any suggestions is of great help. >>> >>> Thanks. >>> Raghu. >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Maybe Matching Threads
- [LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
- [LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
- [LLVMdev] Modifying the patterns/ instruction selection phase in LLVM 2.7
- [Sparc] Load address with SETHI
- [LLVMdev] A question of Sparc assembly generated by llc