<div dir="ltr">Hello once again,<div><br></div><div>I managed to create a second version of my patch. This time, I don't disallow FrameIndex from the IndirectMemRefOp optimization. Instead, I track the number of unique SDValues with the reasoning that each of them will require a register. In case the number of them grows too much, I fall back to the old logic that handles registers spills gracefully (instead of the register allocator error).</div><div><br></div><div>Regards,</div><div>Gustaw<br><div class="gmail_extra"><br><div class="gmail_quote">2014-09-21 19:11 GMT+02:00 Gustaw Smolarczyk <span dir="ltr"><<a href="mailto:wielkiegie@gmail.com" target="_blank">wielkiegie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello all.<div><br></div><div>This is my first patch to the LLVM project. I hope you will find it useful.</div><div><br></div><div>This patch improves the experimental stackmap and patchpoint intrinsics.</div><div>It tries to use the IndirectMemRefOp in more cases. Currently, they are only emitted for values spilled to a local stack. However, they could be applied for any [Register + Offset] memory load.</div><div><br></div><div>I had problems with indirect FrameIndex references. Because my code can't retrieve the offset of such a memory reference, it allocates a register for every such access, which caused one of the tests to fail. This is why I disabled it for this case.</div><div><br></div><div>I am not very familiar with the LLVM code base. I might have done something in a roundabout or simply incorrect way. I would be glad if I had been given some pointers.</div><div><br></div><div>Regards,</div><div>Gustaw</div></div>
</blockquote></div><br></div></div></div>