[llvm-commits] [PATCH] update getPointerTo to handle multiple address spaces

Duncan Sands baldrick at free.fr
Tue Oct 30 00:46:23 PDT 2012


Hi Micah,

On 29/10/12 22:48, Villmow, Micah wrote:
> I would prefer to wait on doing any major refactoring. This is way outside of the original scope of the work that I had original planned/agreed on doing. This original scope of the work was basically:
> 1) Move TargetData to DataLayout.
> 2) Update all clients.
> 3) Add in support for multiple address spaces to DataLayout.
> 4) Update clients to add in support for multiple address spaces having varying pointer sizes.
>
> Now, ChrisL wants DataLayout removed from being a pass and moved into the Module(Bug11936), and now you want a refactor of the pointer types. Now, after having dealing with this for the last few months, I agree, the code is not as clean as it could be, but stopping everything just to re-factor, I don't agree with, when most of the changes have already gone in.
>
> Otherwise I'll just be stopping one set of work when it is almost done to move on to another project that again is not guaranteed to not be affected by the same scope creep. LLVM 3.2 branches in about 2 weeks, and as it currently is, multiple address space support is not complete, but almost finished. I would highly prefer to get it working by 3.2 and then refactor the code that has shown to be problematic.

personally I would rather see the whole thing reverted rather than having a poor
implementation in 3.2.  At least the API should be correct (even if not all bugs
are shaken out), I will try to give you a hand with this (i.e. cleaning up your
points 3 and 4).  I think changing DataLayout from being a pass to something
else can wait until after 3.2.   I'm not sure what you mean by Chandler wanting
a refactor of the pointer types.  If you mean changing your datalayout methods
to assert when not passed a pointer (as opposed to using an address space of 0)
then I agree with Chandler that it is essential to fix this ASAP.  The more you
add places that make use of the current bogus behaviour the harder it will get
to fix later.  This is the main thing I will try to help you out with.

Ciao, Duncan.



More information about the llvm-commits mailing list