[LLVMdev] Two Regalloc Enhancements

Alireza.Moshtaghi at microchip.com Alireza.Moshtaghi at microchip.com
Fri Jul 24 10:08:20 PDT 2009


These seem to be the exact opposite of what the PIC16 port requires.
However, since the behavior is controllable I don't think they will
break our port.

Just a little background, PIC16 only has one register; so preloading it
is just going to cause too many useless spills...

Regards,
Ali

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On
> Behalf Of David Greene
> Sent: Thursday, July 23, 2009 12:42 PM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Two Regalloc Enhancements
> 
> We have two features for register allocation we'd like to contribute
if
> folks
> think they are worthwhile.  We want to get a read on whether they will
be
> useful to people.
> 
> The first features backschedules reloads during the spilling phase.
As
> reloads are generated, we have some very simple code to try to
schedule
> them
> as far ahead of the use as possible.
> 
> The second features modifies linearscan to try to spread register
usage
> out a
> bit.  Rather than always grabbing the first free register in the
> allocatable
> list, it remembers the last few registers recently assigned and does
not
> reuse
> them unless there are no other registers available.  This tends to
help
> the
> backscheduling code by distributing register usage and providing more
> scheduling freedom.  It also can induce spilling where none was there
> before
> if the allocator has "just enough" registers.  We haven't noticed any
> serious
> performance problems in practice.
> 
> With both patches, we have seen performance improvements on some
codes.
> 
> I know there's some work on post-ra scheduling going on which would
> probably
> supercede the reload backscheduling code.  If that's coming soon,
there's
> probably not much point in contributing it.  The "round-robin"
register
> assignment would help and post-ra scheduler.
> 
> What's the community's opinion on whether these two features are worth
> committing to the public repository?
> 
>                                    -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list