similar to: [LLVMdev] More efficient way of going over memory based instructions

On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote: > So, my question is, should isIdenticalTo take the memoperands into account? Is my patch correct? I almost feel like isIdenticalTo needs to be added to MachineMemOperand class. The MachineMemOperands are supposed to be used for optimizations only, your code should still be correct when stripping all memory operands. I think you would be

> -----Original Message----- > From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > Sent: Tuesday, January 04, 2011 11:55 AM > To: Villmow, Micah > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Bug in MachineInstr::isIdenticalTo > > > On Jan 4, 2011, at 11:08 AM, Villmow, Micah wrote: > > > So, my question is, should isIdenticalTo take the

I have ran across a case where the function isIdenticalTo is return true for instructions that are not equivalent. The instructions in question are load/store instructions, and is causing a problem with MachineBranchFolding. The problem is this, I have two branches of a switch statement that are identical, except for the size of the store. Here is some cut-down LLVM-IR to showcase the issue:

Jakob, Here is my implementation of getAllocatableSet: BitVector AMDILRegisterInfo::getAllocatableSet(const MachineFunction& MF, const TargetRegisterClass *RC = NULL) const { BitVector Allocatable(getNumRegs()); Allocatable.clear(); return Allocatable; } Micah -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Monday, May 03, 2010 9:52 AM To:

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

After a bunch more investigate, I've seem to have figured out what is going on here. The MachineFunction holds a vector of MachineBasicBlocks and it is this vector that is traversed by the MachineFunction iterator when printing out instructions. The problem is occurring when a modification to the CFG moves around so that the ordering of them is different. Even if the pred/succ blocks are

On Oct 13, 2008, at 5:14 PMPDT, Villmow, Micah wrote: > As stated in an earlier email, I am working on getting break/ > continue to work correctly for my backend, but I ran into another > issue with codegen and the CFG. It seems that code gen is not done > based on the CFG, but rather on the block numbers, and the function > call MachineFunction::RenumberBlocks doesn’t

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

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

On Apr 29, 2010, at 2:06 PM, Villmow, Micah wrote: > Ping. Anyone have any idea on how to fix this? Does your getAllocatableSet() return a BitVector that is at least getNumRegs() bits long? Otherwise this doesn't work: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); NonAllocatableRegs.flip();

As stated in an earlier email, I am working on getting break/continue to work correctly for my backend, but I ran into another issue with codegen and the CFG. It seems that code gen is not done based on the CFG, but rather on the block numbers, and the function call MachineFunction::RenumberBlocks doesn't renumber the blocks based on the CFG. So how can I modify the CFG so that when codegen

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,

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:

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

On Sep 25, 2008, at 10:49 AM, Villmow, Micah wrote: > I am having trouble trying to figure out two pieces of information > from attempting to map arguments to registers. > How do I determine, based on the argument name, which register the > value is supposed to be assigned to? > I can hard-coded it currently and it will be correct 100% of the > time with the current set of

On Thu, Oct 8, 2009 at 11:28 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Jeffrey Yasskin [mailto:jyasskin at google.com] >> Sent: Thursday, October 08, 2009 11:09 AM >> To: Villmow, Micah >> Cc: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Instructions that cannot be duplicated >>

> -----Original Message----- > From: Jeffrey Yasskin [mailto:jyasskin at google.com] > Sent: Thursday, October 08, 2009 11:09 AM > To: Villmow, Micah > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Instructions that cannot be duplicated > > On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > > > >

On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Eli Friedman [mailto:eli.friedman at gmail.com] >> Sent: Wednesday, October 07, 2009 5:50 PM >> To: Villmow, Micah >> Cc: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Instructions that cannot be duplicated >>

I am having trouble trying to figure out two pieces of information from attempting to map arguments to registers. How do I determine, based on the argument name, which register the value is supposed to be assigned to? I can hard-coded it currently and it will be correct 100% of the time with the current set of assumptions, but I would rather determine it dynamically so that I can change my

> -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Wednesday, October 07, 2009 5:50 PM > To: Villmow, Micah > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Instructions that cannot be duplicated > > On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah <Micah.Villmow at amd.com> > wrote: > > Is there a current