<div dir="ltr">The count should be exact, so I implement my analysis in preEmitPass.<div><br></div><div id="">I can't imagine how this special node will be implemented. Will this node be metadata, a special instruction, a special register class or another class? </div>
<div id="">I will use load and store to access shared memory. Besides, the shared memory is allocated dynamically, and may be deleted when resizing or canceling occurs.</div><div id=""><br></div><div id="">I won't change other parts of IR.</div>
<div id=""><br></div><div id="aeaoofnhgocdbnbeljkmbjdmhbcokfdb-mousedown"><br></div><div id="aeaoofnhgocdbnbeljkmbjdmhbcokfdb-mousedown">Antony</div><div id=""><br></div><div id=""><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/8/8 Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Does this count have to be exact, or just an accurate approximation? The back-end may add/remove registers fairly late in the codegen process, so if you need an exact count you may need to run *just* before the assembly printer.<div>
<br></div><div>Perhaps we could introduce a special machine node that represents a shared memory allocation. The node's value would be the shared address space pointer of the allocation, and the assembly printer would turn that into a ".shared .bX ..." variable. Would that solve your issue? Or do you need to change other parts of the IR as well?</div>
</div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 7:29 AM, Anthony Yu <span dir="ltr"><<a href="mailto:swpenim@gmail.com" target="_blank">swpenim@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, total number of PTX registers that will be emitted is exactly what I need. It's hard to figure out this in LLVM IR level. </div>
<div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/7 Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Is there any way you could approximate the register/instruction usage and perform live-range analysis in a higher-level LLVM IR pass? I'm not sure how useful NVPTXRegisterInfo would be anyway. Unlike backends that target "real" ISAs, these structures do not contain any special properties about registers or instructions, like cost or scheduling information. Are you trying to figure out the total number of PTX registers that will be emitted?</div>
<div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Wed, Aug 7, 2013 at 7:06 AM, Anthony Yu <span dir="ltr"><<a href="mailto:swpenim@gmail.com" target="_blank">swpenim@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">OK. I know what you mean.........<div><br></div><div>Simply speaking, I want to do some optimizations for PTX, and the information I need is similar to a register allocator. I know PTX is virtual ISA, but I will use PTX as the input of the simulator, gpgpu-sim, so it makes sense.</div>
<div>Whether to insert shared memory is depend on the analysis that needs LiveAnalysis, PTX InstrInfo, PTX RegisterInfo, etc. That's why I need to add global variables in MachineFunctionPass. <span><font color="#888888"><br>
</font></span></div><span><font color="#888888"><div>
<br></div><div>Antony</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/6 Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, global variables are the only way to access shared memory.<div><br></div><div>I'm just trying to get an idea of what you're aiming to accomplish to see if we can improve on the interface here. A MachineFunctionPass runs after instruction selection and relying on doInitialization to run before instruction selection is an implementation detail that I do not believe is guaranteed anywhere (I could be wrong!). And modifying the IR does in fact violate the rules for a MachineFunctionPass (see bullet 1 in <a href="http://llvm.org/docs/WritingAnLLVMPass.html#the-machinefunctionpass-class" target="_blank">http://llvm.org/docs/WritingAnLLVMPass.html#the-machinefunctionpass-class</a>).</div>
<div><br></div><div>If you explain what you're trying to accomplish, I can try to help figure out a good approach here. There very well may be limitations to the current infrastructure that need to be fixed.</div></div>
<div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Tue, Aug 6, 2013 at 1:25 AM, Anthony Yu <span dir="ltr"><<a href="mailto:swpenim@gmail.com" target="_blank">swpenim@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I want to create share memory in my MachineFunctionPass, and insert load/store instruction for it. The way to create share memory is to add global variables which are in share memory address space (not sure if it is the only way). Therefore, I should add global variables in fixed size in doInitialization, and record its real size in other place like MachineModuleInfo. Then modify or query its real size from that place instead of size of variable.<span><font color="#888888"><div>
<br></div><div><br></div><div>Antony</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/6 Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Can you tell us a bit more about what you're trying to accomplish?<div><br></div><div>Changes to the IR performed during MachineFunctionPass::doInitialization will likely propagate down through code generation, but at that point what is the purpose of using a MachineFunctionPass? You won't have any analysis or instruction information available until runOnMachineFunction.</div>
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Mon, Aug 5, 2013 at 12:00 PM, Anthony Yu <span dir="ltr"><<a href="mailto:swpenim@gmail.com" target="_blank">swpenim@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Micah,<div><br></div><div>Thanks for your help. I will study on that code.</div><div><br></div><div><br>
</div><div>Justin,<br></div><div><br></div><div>Sorry for my misleading word. Local memory in OpenCL is the same as share memory in CUDA. What I mean is share memory, so MachineFrameInfo is not suitable to me.</div>
<div>And I need codegen data, so FunctionPass is also not suitable.</div><div>Anyway, thanks for the suggestion.</div><span><font color="#888888"><div>
<br></div><div>Antony</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/5 Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If you're running a MachineFunctionPass, then the code has already been lowered to machine instructions and modifying the original IR will most likely not do what you want. You should only be using the IR as an immutable object for reference. If you want to change the IR, I would suggest using a FunctionPass instead of a MachineFunctionPass. Unless you need codegen data.<div>
<br></div><div>At the MachineInstr level, to allocate local memory you can use the MachineFrameInfo interface. This provides methods like CreateStackObject to allocate a new stack slot (which will be lowered to local memory in PTX). The return value of these methods is an integer that represents a FrameIndex. You can treat this as a pointer to your allocated object. You will also need to emit the proper MachineInstr-level loads and stores to access the object.</div>
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Mon, Aug 5, 2013 at 11:00 AM, Anthony Yu <span dir="ltr"><<a href="mailto:swpenim@gmail.com" target="_blank">swpenim@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Micah,<div><br></div><div>As you expected, I am trying to create local memory but in the NVPTX backend. It's really not convenient that I can't create local memory in runOnMachineFunction.</div>
<div>Hmm....</div><div>Since I should do it at doInitialization stage, I also need to do some tricks in global variable and AsmPrinter to resize it.</div><div>Did you use the similar way?</div><span><font color="#888888">
<div><br></div><div>Antony</div><div><br></div><div><br></div></font></span></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/8/5 Micah Villmow <span dir="ltr"><<a href="mailto:micah.villmow@smachines.com" target="_blank">micah.villmow@smachines.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Antony,<br>
What are you trying to accomplish in this case? I did something very similar in the AMDIL backend, but it was not the cleanest solution and you are correct it has to be do at doInitialization stage and not at runOnMachineFunction.<br>
Micah<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a>]<br>
> On Behalf Of Antony Yu<br>
> Sent: Monday, August 05, 2013 3:41 AM<br>
> To: <a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a><br>
> Subject: [LLVMdev] Can I add GlobalVariable in MachineFunctionPass ?<br>
><br>
> Hello,<br>
><br>
> I want to add a global variable of arrayType in my MachineFunctionPass.<br>
> However, I only get const Module from<br>
> MachineFunction.getMMI().getModule().<br>
> I can't add any global variable to a const Module.<br>
> Another way is to add a global variable in doInitialization in my<br>
> MachineFunctionPass, but I can't determine the size of my arrayType for<br>
> global variable in doInitialization.<br>
><br>
> Is there any suggestion that can help me achieve this?<br>
><br>
> Thanks in advance.<br>
> Antony Yu<br>
><br>
><br>
<span><font color="#888888">><br>
> --<br>
> View this message in context: <a href="http://llvm.1065342.n5.nabble.com/Can-I-add-" target="_blank">http://llvm.1065342.n5.nabble.com/Can-I-add-</a><br>
> GlobalVariable-in-MachineFunctionPass-tp60165.html<br>
> Sent from the LLVM - Dev mailing list archive at Nabble.com.<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</font></span></div>
</blockquote></div><br></div>