[LLVMdev] Heads up, I've backed out significant amounts of the multiple address space conversion changes

[Micah Villmow]

The reason why I say it should be done in a separate branch is that the final design is not necessarily the same as the first initial implementation. There are things that will break and this kind of change touches almost everything, not just the core LLVM libraries. It is hard to get right the first time, and developing it in a sandbox will dramatically decrease the amount of churn that will show up in all the various components on mainline.

Just from my experience, the following items have to be solved or considered that my first implementation didn’t handle. Now I am not doing this work, and I haven’t looked at this in many months, so this is based on my memory, so I might be off.


·         Global constant expression handling API’s assume pointer size of address space zero, what about constants in different address spaces?

·         Alloca always assumes address space zero pointer sizes, how does it work for different address spaces?

·         How to test everything without exponentially increasing the number of tests?

That is in addition to the large amount of churn to not only the internal/external LLVM API’s, but also its components(clang, lldb, etc…).

Now if you break everything into tiny patches, it might be manageable on mainline, but even changing one API can cascade to tens of files.

Micah
From: chandlerc at google.com [mailto:chandlerc at google.com] On Behalf Of Chandler Carruth
Sent: Thursday, June 27, 2013 4:18 PM
To: Micah Villmow
Cc: Matt Arsenault; Chandler Carruth; LLVM Developers Mailing List
Subject: Re: [LLVMdev] Heads up, I've backed out significant amounts of the multiple address space conversion changes


On Thu, Jun 27, 2013 at 12:49 PM, Micah Villmow <micah.villmow at smachines.com<mailto:micah.villmow at smachines.com>> wrote:
That said, changes of this magnitude should be done in a branch instead of mainline trunk.

I strongly disagree. If you think this is the case, we should probably start a new thread (rather than ressurecting this one) with the context of what you want to do and why you think it should be on a branch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130627/99c3608d/attachment.html>