[LLVMdev] Avoiding MCRegAliasIterator with register units

[Chad Rosier]

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?

Jakob suggestion was to remove the static tables, thus shrinking the object file size.  Without the static tables, however, we do need to compute the aliases dynamically.
We're intentionally making a tradeoff between compile-time and object file size with the hope that the overhead of dynamically computing the aliases is minimal.  I
should also note that I'm not actually building/growing any list (i.e., no malloc/free), but rather iterating over the other static tables (i.e., MCRegUnits, MCRegUnitRoots,
and MCSuperRegs).  I'll attach the patch for the curious...

> 
> 
> 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.

One would think, but you never know.

> 
> 
> 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. 

I'll throw -O3 into the mix..  :)  

> 
> Somehow it sounds as though you'll find more performance regressions than improvements, but that's my poor assumptions based on nothing concrete. ;)

Jakob also suggested minimizing the use of the MCRegAliasIterator because most of the clients can be rewritten in terms of other iterators.  If necessary, I'll
leave it to Jakob to explain this point further.

  Chad

> 
> cheers,
> --renato

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130524/0f7e98da/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MCRegAliasIterator.patch
Type: application/octet-stream
Size: 10594 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130524/0f7e98da/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130524/0f7e98da/attachment-0001.html>