[llvm-commits] First patch to add support for variable address spaces to optimizers

[Villmow, Micah]

> -----Original Message-----
> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> Sent: Wednesday, October 10, 2012 9:24 PM
> To: Nick Lewycky
> Cc: Villmow, Micah; llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm-commits] First patch to add support for variable
> address spaces to optimizers
> 
> On Wed, Oct 10, 2012 at 9:09 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> > Eli Friedman wrote:
> >>
> >> On Wed, Oct 10, 2012 at 1:27 PM, Villmow,
> >> Micah<Micah.Villmow at amd.com>
> >> wrote:
> >>>
> >>> This patch starts enabling proper use of the variable address space
> >>> throughout LLVM.
> >>> What this does is when it is known, it passes in the address space
> >>> to the data layout for some functions.
> >>> The next patch will contain the more intrusive changes of
> >>> getIntPtrType/get*PtrTy/getPointerTy.
> >>
> >>
> >> I'm sort of uncomfortable with the number of places you're hardcoding
> >> "0"; can you add a function to DataLayout with a more explanatory
> >> name?
> >>
> >> Index: include/llvm-c/Target.h
> >> ===================================================================
> >> --- include/llvm-c/Target.h     (revision 165622)
> >> +++ include/llvm-c/Target.h     (working copy)
> >> @@ -170,7 +170,7 @@
> >>
> >>   /** Returns the pointer size in bytes for a target.
> >>       See the method llvm::DataLayout::getPointerSize. */ -unsigned
> >> LLVMPointerSize(LLVMTargetDataRef);
> >> +unsigned LLVMPointerSize(LLVMTargetDataRef, unsigned AS);
> >>
> >> This change isn't acceptable; the C API is stable.  Add a new
> >> function if necessary.
> >
> >
> > Hey Eli, I'm not sure this is reasonable. There is a need to keep the
> > C API ABI stable for libLTO and libIndex and a few high-level C
> > libraries, but the main purpose of these C wrappers for all the C++
> > functions is to allow people to write language-specific bindings on
> > top LLVM, and they don't need ABI stability. I've mentioned in the
> > past that we should remove the ABI-stability requirement except for
> > the libraries which have users that are really relying on that ABI
> guarantee.
> 
> Hmm... I'm not necessarily opposed, but can we document this somewhere?
[Villmow, Micah] I agree, the rules on the C API should be well documented, this  is the second time I could've made changes to them, but I don't know exactly what is and isn't allowed.
> 
> -Eli