search for: isspillable

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

...PTR RC, try to evict: call canEvictInterference() for virtY which interferes with virtX, returns true. evict and unassign virtX and assign physreg to virtY. 3) for a virtZ which also belongs to the PTR RC, try to evict: call canEvictInterference() for virtZ which interferes with virtY, both VirtReg.isSpillable() and Intf->isSpillable() return false, can't evict, wait for a second round and queue new interval. 4) do some work unrelated to these vregs. 5) when selectOrSplit is called again for virtZ it falls through down to the return ~0u line and fails. This issue can be very easily reproduced wi...

Hi @ll, over the past year we gained more experience with the patchpoint/stackmap/statepoint intrinsics and it exposed limitations in the stackmap format. The following proposal includes feedback and request from several interested parties and I would like to hear your feedback. Missing correlation between functions and stackmap records: Originally the client had to keep track of the ID to know

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

...l > canEvictInterference() for virtY which interferes with virtX, returns true. > evict and unassign virtX and assign physreg to virtY. > 3) for a virtZ which also belongs to the PTR RC, try to evict: call > canEvictInterference() for virtZ which interferes with virtY, both > VirtReg.isSpillable() and Intf->isSpillable() return false, can't evict, > wait for a second round and queue new interval. > 4) do some work unrelated to these vregs. > 5) when selectOrSplit is called again for virtZ it falls through down to > the return ~0u line and fails. > > > This issue...

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

> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com> wrote: > > Regarding Call-site size specification: > > CoreCLR (https://github.com/dotnet/coreclr <https://github.com/dotnet/coreclr>) requires the size of the Call-instruction to be reported in the GCInfo encoding. > > The runtime performs querries for StackMap records using