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

[Villmow, Micah]

Attached a new patch.
I've added two new API's to the C api that allows querying of pointer size on a per address space basis and also allows generation of an integer that is sized for the various address spaces.
I also removed the FIXME's and as far as I can tell, all the places with '0' want the default address space.
________________________________________
From: Eli Friedman [eli.friedman at gmail.com]
Sent: Wednesday, October 10, 2012 3:52 PM
To: Villmow, Micah
Cc: 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 1:43 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
>
>
>> -----Original Message-----
>> From: Eli Friedman [mailto:eli.friedman at gmail.com]
>> Sent: Wednesday, October 10, 2012 1:38 PM
>> To: Villmow, Micah
>> Cc: 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 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?
> [Villmow, Micah] Well, the places where it is hard coded is locations where I could not find any way to get the address space. This usually is in locations where the address space is not relevant, but the pointer size needs to be known. In this case, 0 is the default.
> I could add in a function to get the default, but my assumption was that it is 0 in LLVM and as such, put 0.
> Another option is I always have a default argument in the final patch and remove the locations where 0 is hard coded.

Hmm... it looked like a lot of places what we were looking for is the
address of a code pointer, which is something specific (just not with
an associated function that returns an address-space).

Some places, I agree, there isn't an alternative.

>>
>> 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.
> [Villmow, Micah] Sorry, I originally had this as a default argument of 0 to see if there were any locations that required changing.
> Are default arguments allowed for the C API? If so, that would fix this issue, otherwise I'll add a new API LLVMPointerSizeForAS.

It's the *C* API, so no default arguments.

-Eli

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 001-patch-to-support-per-address-space-data-layout.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121010/9da5604b/attachment.txt>