[LLVMdev] Avoiding MCRegAliasIterator with register units
Jakob Stoklund Olesen
stoklund at 2pi.dk
Fri May 24 11:39:18 PDT 2013
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.
More information about the llvm-dev