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

TL;DR: See subject. That is all.

TL;DR: See subject. That is all.
----

First off, I want to say I'm sorry for doing this. =/

It's a hard call, but thank you for doing this. I fully agree that it was the right thing to do, it doesn't make sense to force a major change like this in right before the 3.2 branch date.

-Chris

First off I want to thank everyone for helping out with this. While I don't like that the code was backed out, I would do the same thing in your shoes given the same situation.

So, what should the next step be? I'm still catching up on what exactly is still there and what was removed, but that shouldn't stop the discussion from continuing.

Micah

I guess I'll try picking this back up. What were the problems exactly from a design perspective?

Outside of what was listed below, which you would have to go back into the other emails/reviews to get into more details, I believe the handling of global constants expressions was problematic with the API's that I had implemented.

That said, changes of this magnitude should be done in a branch instead of mainline trunk.

Micah

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.

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

I just wanted to say that we are also interested in having more support for multiple address spaces (but maybe with focus on somewhat different aspects than added by Micah). We currently maintain changes internally, and I hopefully will get time to look at pushing our changes upstream in six months or so.

/Patrik Hägglund