llvm dev - Jun 2013 - [LLVMdev] Register coalescer and reg_sequence (virtual super-regs)

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? That would be
great. (I don't sync too often to avoid churn with my TD.)

Joe


On Fri, May 31, 2013 at 4:21 PM, Jakob Stoklund Olesen <stoklund at
2pi.dk>wrote:
>
> On May 31, 2013, at 4:07 PM, Joe Matarazzo <joe.matarazzo at
gmail.com>
> wrote:
>
> > The register coalescer treats virtual super register classes -- a
> sequential register range composed of multiple hardware registers -- as a
> register with sub registers. When making coalescing decisions it thinks
> that the virtual super reg interferes with sub reg instances, even though
> in reality they shouldn't conflict. That is, they are individual
registers
> and would be better compared as such for register coalescing decisions
> (CoalescerPair::Partial = 0).
> >
> > For example, I have a super reg that has r20, r21, r22, and r23
physical
> registers. This super reg is the dest of a reg_sequence which generates 4
> COPY MIs. The first COPY coalesces (merging into r20), but the vregs for
> r21-r23 (SUPER_RC:%vreg50:subreg1..subreg3) are never coalesced after that
> because doing so generates inteference on %vreg50, the "parent"
super reg.
> >
> > Is there a way to work around this? It causes unnecessary copies.
>
> Is this happening on trunk, or are you using an old version of LLVM?
>
> /jakob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130531/d4087018/attachment.html>

On May 31, 2013, at 4:59 PM, Joe Matarazzo <joe.matarazzo at gmail.com>
wrote:
> 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?
Yes, it’s been fixed recently.

/jakob

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.

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?

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.


Thanks,
Joe



On Fri, May 31, 2013 at 5:00 PM, Jakob Stoklund Olesen <stoklund at
2pi.dk>wrote:
>
> On May 31, 2013, at 4:59 PM, Joe Matarazzo <joe.matarazzo at
gmail.com>
> wrote:
>
> > 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?
>
> Yes, it’s been fixed recently.
>
> /jakob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130619/79278774/attachment.html>