<div dir="ltr">Was it the subreg lane masks / mapping that was added to address the missed coalescing?  This solution is nice, but I don't think it'll work for me. I have 8-element vector registers that can be grouped into virtual super regs for bulk save/restore, and as soon as I have more than 4 in a tuple, the unsigned int used to hold the lane masks overflows and switches over to the "bit 31 set == lanes unresolvable" mode, and coalescing fails.<div>
<br></div><div>What about moving the lane masks to a BitVector, that wouldn't need to be constrained artificially? Too much of a performance impact going that way?</div><div><br></div><div>I'd be open to any thoughts/suggestions. I studied the ARM s_sub/d_sub/q_sub structure but that fits within the 32 bit lane mask. I also thought that LDM/STM would be similar, but the registers are physically enumerated, which is different from these virtual super reg frames I'm trying to construct.</div>
<div><br></div><div><br></div><div>Thanks,</div><div>Joe</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 31, 2013 at 5:00 PM, Jakob Stoklund Olesen <span dir="ltr"><<a href="mailto:stoklund@2pi.dk" target="_blank">stoklund@2pi.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On May 31, 2013, at 4:59 PM, Joe Matarazzo <<a href="mailto:joe.matarazzo@gmail.com">joe.matarazzo@gmail.com</a>> wrote:<br>
<br>
> I think the last time I pulled from trunk was probably end of last year. Some time ago. Does your reply intimate it's fixed on trunk?<br>
<br>
</div>Yes, it’s been fixed recently.<br>
<span class="HOEnZb"><font color="#888888"><br>
/jakob<br>
<br>
</font></span></blockquote></div><br></div>