[LLVMdev] Can I add GlobalVariable in MachineFunctionPass ?

Justin Holewinski justin.holewinski at gmail.com
Thu Aug 8 05:23:20 PDT 2013 

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.

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?


On Thu, Aug 8, 2013 at 7:29 AM, Anthony Yu <swpenim at gmail.com> wrote:

> 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.
>
>
> 2013/8/7 Justin Holewinski <justin.holewinski at gmail.com>
>
>> 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?
>>
>>
>> On Wed, Aug 7, 2013 at 7:06 AM, Anthony Yu <swpenim at gmail.com> wrote:
>>
>>> OK. I know what you mean.........
>>>
>>> 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.
>>> 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.
>>>
>>> Antony
>>>
>>>
>>> 2013/8/6 Justin Holewinski <justin.holewinski at gmail.com>
>>>
>>>> Yes, global variables are the only way to access shared memory.
>>>>
>>>> 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
>>>> http://llvm.org/docs/WritingAnLLVMPass.html#the-machinefunctionpass-class
>>>> ).
>>>>
>>>> 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.
>>>>
>>>>
>>>> On Tue, Aug 6, 2013 at 1:25 AM, Anthony Yu <swpenim at gmail.com> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> Antony
>>>>>
>>>>>
>>>>>
>>>>> 2013/8/6 Justin Holewinski <justin.holewinski at gmail.com>
>>>>>
>>>>>> Can you tell us a bit more about what you're trying to accomplish?
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 5, 2013 at 12:00 PM, Anthony Yu <swpenim at gmail.com>wrote:
>>>>>>
>>>>>>> Micah,
>>>>>>>
>>>>>>> Thanks for your help. I will study on that code.
>>>>>>>
>>>>>>>
>>>>>>> Justin,
>>>>>>>
>>>>>>> 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.
>>>>>>> And I need codegen data, so FunctionPass is also not suitable.
>>>>>>> Anyway, thanks for the suggestion.
>>>>>>>
>>>>>>> Antony
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2013/8/5 Justin Holewinski <justin.holewinski at gmail.com>
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 5, 2013 at 11:00 AM, Anthony Yu <swpenim at gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Micah,
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>> Hmm....
>>>>>>>>> Since I should do it at doInitialization stage, I also need to do
>>>>>>>>> some tricks in global variable and AsmPrinter to resize it.
>>>>>>>>> Did you use the similar way?
>>>>>>>>>
>>>>>>>>> Antony
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2013/8/5 Micah Villmow <micah.villmow at smachines.com>
>>>>>>>>>
>>>>>>>>>> Antony,
>>>>>>>>>>  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.
>>>>>>>>>> Micah
>>>>>>>>>>
>>>>>>>>>> > -----Original Message-----
>>>>>>>>>> > From: llvmdev-bounces at cs.uiuc.edu [mailto:
>>>>>>>>>> llvmdev-bounces at cs.uiuc.edu]
>>>>>>>>>> > On Behalf Of Antony Yu
>>>>>>>>>> > Sent: Monday, August 05, 2013 3:41 AM
>>>>>>>>>> > To: llvmdev at cs.uiuc.edu
>>>>>>>>>> > Subject: [LLVMdev] Can I add GlobalVariable in
>>>>>>>>>> MachineFunctionPass ?
>>>>>>>>>> >
>>>>>>>>>> > Hello,
>>>>>>>>>> >
>>>>>>>>>> > I want to add a global variable of arrayType in my
>>>>>>>>>> MachineFunctionPass.
>>>>>>>>>> > However, I only get const Module from
>>>>>>>>>> > MachineFunction.getMMI().getModule().
>>>>>>>>>> > I can't add any global variable to a const Module.
>>>>>>>>>> > Another way is to add a global variable in doInitialization in
>>>>>>>>>> my
>>>>>>>>>> > MachineFunctionPass, but I can't determine the size of my
>>>>>>>>>> arrayType for
>>>>>>>>>> > global variable in doInitialization.
>>>>>>>>>> >
>>>>>>>>>> > Is there any suggestion that can help me achieve this?
>>>>>>>>>> >
>>>>>>>>>> > Thanks in advance.
>>>>>>>>>> > Antony Yu
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > --
>>>>>>>>>> > View this message in context:
>>>>>>>>>> http://llvm.1065342.n5.nabble.com/Can-I-add-
>>>>>>>>>> > GlobalVariable-in-MachineFunctionPass-tp60165.html
>>>>>>>>>> > Sent from the LLVM - Dev mailing list archive at Nabble.com.
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Justin Holewinski
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Justin Holewinski
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Thanks,
>>>>
>>>> Justin Holewinski
>>>>
>>>
>>>
>>
>>
>> --
>>
>> Thanks,
>>
>> Justin Holewinski
>>
>
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130808/31fed470/attachment.html>

More information about the llvm-dev mailing list