[LLVMdev] Avoiding MCRegAliasIterator with register units

[Jakob Stoklund Olesen]

On May 24, 2013, at 10:08 AM, Renato Golin <renato.golin at linaro.org> wrote:

> On 24 May 2013 17:39, Chad Rosier <mcrosier at apple.com> wrote:
> One side effect of dynamically computing the aliases is that the iterator does not guarantee that the entries are ordered or that duplicates have been removed.
> 
> Hi Chad,
> 
> Sounds like you're growing the list (thus the lookup time), rather than shrinking, as I take it was Jacob's original intention?
> 
> 
> The documentation seems to imply this is a safe assumption and I haven't found a client that requires these attributes (i.e., strict ordering and uniqueness).
> 
> I don't think it should matter for the purposes of aliasing.
> 
> 
> I also setup a LNT tester and found no execution-time failures on x86 for -O0 and -O2 using the llvm test-suite and externals test-suite (i.e., SPEC95/2K/2K6, etc.).
> 
> I'm wondering why not O3, too? That'll expose vector selection as well, not just VFP, which is a big source of super-registers, at least on ARM. 
> 
> Somehow it sounds as though you'll find more performance regressions than improvements, but that's my poor assumptions based on nothing concrete. ;)

My thinking is that we should try to avoid using MCRegAliasIterator, and use MCRegUnitIterator instead.

That way, it is less of a problem to make MCRegAliasIterator a bit slower in order to save table space.

Thanks,
/jakob