Hi Borja<div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Lang, thanks for the suggestion :) it's very interesting. I'll take a read to the email you've pointed out there to understand how it works. Btw, does this mean that only your allocator is able to handle or support this type of constraint?<br>


</blockquote><div><br></div><div>I believe so. The other allocators can support pairs, but you have to introduce a new register class to describe them, which can lead to the issues you've already seen.</div><div><br>
</div><div>The PBQP allocator lets you keep your original register classes and describe the constraint that certain virtual registers need to be allocated adjacent physicals. The Scholz/Eckstein paper I referenced has an example of an architecture where pairing is a requirement and they show how to encode this using infinite costs to prevent illegal non-adjacent assignments. You can do better still. Since your pairs are an optimization rather than a requirement you can encode the cost of failing to assign adjacent physicals and let the PBQP solver try to find a minimal cost solution.</div>
<div><br></div><div>You'll still have to combine the instructions yourself, but at least the pairing will be taken care of. Perhaps you can alter your instruction scheduling to try to keep copies together. Or you can make your copy combiner a bit smarter and have it check data dependencies to see if code can be shuffled to enable you to combine extra moves?</div>
<div><br></div><div>- Lang.</div></div></div>