search for: stackobject

...9;StackSize' was not declared in this scope /usr/src/Lang/llvm/include/llvm/CodeGen/MachineFrameInfo.h: In member function 'void llvm::MachineFrameInfo::setObjectSize(int, int)': /usr/src/Lang/llvm/include/llvm/CodeGen/MachineFrameInfo.h:218: error: 'struct llvm::MachineFrameInfo::StackObject' has no member named 'Size' /usr/src/Lang/llvm/include/llvm/CodeGen/MachineFrameInfo.h: In member function 'void llvm::MachineFrameInfo::setObjectOffset(int, int)': /usr/src/Lang/llvm/include/llvm/CodeGen/MachineFrameInfo.h:254: error: 'struct llvm::MachineFrameInfo::Stack...

Hi Carlo, rather than declaring individual stack variables int x; int y; int z; and so on, which requires you to pass each one, or a pointer to each one, to your function, declare one stack variable of struct type that holds them all: struct StackObjects { int x; int y; int z; ... }; ... struct StackObjects stack; then pass the address of stack to your function, enabling it to access all of the objects on the callers stack. This way you only need to copy a single pointer. This is what GCC's nested function implement...

...: > Hi Carlo, rather than declaring individual stack variables > int x; > int y; > int z; > and so on, which requires you to pass each one, or a pointer to each one, > to your function, declare one stack variable of struct type that holds > them all: > struct StackObjects { > int x; > int y; > int z; > ... > }; > ... > struct StackObjects stack; > then pass the address of stack to your function, enabling it to access all > of the objects on the callers stack. This way you only need to copy a single > po...

...rlo, rather than declaring individual stack variables >> int x; >> int y; >> int z; >> and so on, which requires you to pass each one, or a pointer to each one, >> to your function, declare one stack variable of struct type that holds >> them all: >> struct StackObjects { >> int x; >> int y; >> int z; >> ... >> }; >> ... >> struct StackObjects stack; >> then pass the address of stack to your function, enabling it to access all >> of the objects on the callers stack. This way you only need to copy a single >...

.... > > Ugh. I just found another case I don't think we can synthesize in > asmprinter. We mark rematerialized instructions as well so our performance > guys don't come and ask us why we didn't hoist saomething out of a loop. > :) Here's another question. If we mark StackObjects as spill slots, isn't it possible that stack slot coloring could come along and assign non-spill/reload memory objects to the same slot? If so, it would appear we really do need a flag on MachineInstr to notate all spills and reloads. -Dave

Il 21/08/2011 19:31, Jordy Rose ha scritto: > What I can think of: > 1. Anonymous struct, to avoid a copy. > 2. Use stdarg.h...dangerous but accomplishes what you're looking for. probably it wasn't clear from my first post: I'm talking about LLVM-IR, not C or C++. > 3. Split up F: giant switch statements often indicate that your function is doing several different things.

What I can think of: 1. Anonymous struct, to avoid a copy. 2. Use stdarg.h...dangerous but accomplishes what you're looking for. 3. Split up F: giant switch statements often indicate that your function is doing several different things. (IMHO...) 4. Don't worry about it, it's probably not a bottleneck. (Or rather, profile first...) But no, there's no standard way to do this. Even

On Monday 13 July 2009 15:58, David Greene wrote: > Again, after answering the FI stack slot question, the IR-level instruction > information is the only thing we can't do through asmprinter. I'm open to > other ways of capturing the information that don't require comments in > MachineInstrs. But the information has to be stored somewhere. Ugh. I just found another

...e I don't think we can synthesize in >> asmprinter. We mark rematerialized instructions as well so our >> performance >> guys don't come and ask us why we didn't hoist saomething out of a >> loop. >> :) > > Here's another question. If we mark StackObjects as spill slots, > isn't it > possible that stack slot coloring could come along and assign non- > spill/reload > memory objects to the same slot? If so, it would appear we really > do need > a flag on MachineInstr to notate all spills and reloads. Dave, lets start with...

On 25 Aug 2010, at 02:04, Silvio Ricardo Cordeiro wrote: > On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with

On Sun, Aug 15, 2010 at 10:04 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > > > Is there a way for me to collect statistics about the number of > loads/stores added by the "linearscan" register allocator (just like can be > done with the "local" allocator)? I still haven't

On Monday 13 July 2009 15:46, Chris Lattner wrote: > Well sure, but how is that relevant? Just generate llvm.stoppoint and > isel turns them into debug locs. Just because debugloc isn't on > llvm::Instruction doesn't mean you don't get line numbers :). You're right, it's not a big hurdle. > > Ok, here's an example: > > > > movl

Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-