search for: isspilled

On Sep 11, 2009, at 3:31 PM, David Greene wrote: > Attached is a patch to print asm comments for spill information. > We've discussed the mechanisms before but I wanted to run the > patch by everyone before I start to commit pieces. Some thoughts: The general approach to enhancing CreateStackObject and adding MachineInstr::AsmPrinterFlags seems fine to me! The testcase should

Attached is a patch to print asm comments for spill information. We've discussed the mechanisms before but I wanted to run the patch by everyone before I start to commit pieces. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: spillcomments.patch Type: text/x-diff Size: 58930 bytes Desc: not available URL:

On Monday 14 September 2009 12:32, Chris Lattner wrote: > On Sep 11, 2009, at 3:31 PM, David Greene wrote: > > Attached is a patch to print asm comments for spill information. > > We've discussed the mechanisms before but I wanted to run the > > patch by everyone before I start to commit pieces. > > Some thoughts: > > The general approach to enhancing

Hello Jakob, > Those are some severe constraints on register allocation, but it ought to > be possible anyway. > Indeed, these constraints aren't playing very well with the register allocator :\ > > You may wan't to investigate how RAGreedy::canEvictInterference() is > behaving. > Ok, this is what I've noticed, not sure if it makes sense at all but, regalloc

...6 : Frame Base Register Dwarf RegNum uint16 : Num Frame Registers uint16 : Frame Register Index uint16 : Num StackMap Records uint16 : StackMap Record Index } align to 4 bytes FrameRegister[] { uint16 : Dwarf RegNum int16 : Offset uint8 : Size in Bytes uint8 : Flags { bool : IsSpilled bool : Reserved [7] } } align to 8 bytes StackMapRecord[] { uint64 : PatchPoint ID uint32 : Instruction Offset uint8 : Call size (bytes) uint8 : Flags { bool : HasLiveOutInfo bool : Reserved [7] } uint16 : Num Locations uint16 : Location Index uint16 : Num LiveOuts...

On Dec 17, 2012, at 8:38 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello, > > I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: > > struct ss > { > int a; > int b; > int c; > }; > void

Hello Jakob, I think I've found something interesting that may help you get a better idea of what's going on. While looking at the debug info I noticed that the coalescer was removing lots of copies that could help the allocator make more cross class copies. As a test, I disabled the join-liveintervals option in the coalescer which gave me the surprise of making the regalloc succeed. To

Hello, I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: struct ss { int a; int b; int c; }; void loop(struct ss *x, struct ss **y, int z) { int i; for (i=0; i<z; ++i) { x->c += y[i]->b; } } The problem relies in

...gisters > uint16 : Frame Register Index > uint16 : Num StackMap Records > uint16 : StackMap Record Index > } > > align to 4 bytes > FrameRegister[] { > uint16 : Dwarf RegNum > int16 : Offset > uint8 : Size in Bytes > uint8 : Flags { > bool : IsSpilled > bool : Reserved [7] > } > } > > align to 8 bytes > StackMapRecord[] { > uint64 : PatchPoint ID > uint32 : Instruction Offset > uint8 : Call size (bytes) > uint8 : Flags { > bool : HasLiveOutInfo > bool : Reserved [7] > } > uin...