[LLVMdev] Register Alias Sets

David Greene greened at obbligato.org
Mon Apr 9 12:20:55 PDT 2007


Anton Vayvod wrote:

> Sure, but where these comparisons are needed, for example? RAX and
> EAX alias sets intersect and that's enough to decide that these regs
> can't be assigned simultaneously.

One place these comparisons are used is to build a provably optimal
register class tree in a Smith/Ramsey/Holloway allocator.  Building it
algorithmically is portable to all architectures without requiring
the person writing the machine-specific parts to care about what
the register allocator does.

> In general, that what you would check anyway because for some
> architectures you won't (theoretically, AFAIK) have equal alias sets
> at all, but they'll intersect. Consider the following example (as I
> remember it from some paper on representing irregular 
> architechtures):

As Smith, et. al. point out, such architectures practically don't
exist in the real world.  Most alias sets are either completely
disjoint, exactly equal or entirely contained.

> There are 8 32-bit general purpose registers (R0-R7) and there are 7
>  64-bit registers (W0-W6). Ri reg is a high word of Wi and R(i+1) is
>  a low word of Wi (i runs from 0 to 6). So the alias set for Wi is {
> Ri, R(i + 1)} (you can include Wi, of course). You can't allocate 
> neighbouring W-regs the same time as their alias sets intersect (but
> not equal).

Sure, the alias sets won't be equal, but that's not the point.  The
point is that when they _are_ equal some very important register
allocation optimizations can be done.

BTW, is there an architecture out there that has register overlaps
like this?  Maybe some DSP chip or something?

In any case I can work around the problem by building temporary
alias sets, but that's ugly and wasteful.  It sounds like there
are too many dependencies on the current specification to make
changing it possible, though.

This might be something to think about for the future.

                                      -Dave



More information about the llvm-dev mailing list