[LLVMdev] Can I add GlobalVariable in MachineFunctionPass ?

Tue Aug 6 08:21:50 PDT 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130806/8e2311ac/attachment.html>