[llvm-commits] Intrinsic address space patch

Mon P Wang wangmp at apple.com
Mon Jul 28 11:54:30 PDT 2008


Thanks Dan.  I'll make those changes and revalidate.

   -- Mon Ping

On Jul 28, 2008, at 11:06 AM, Dan Gohman wrote:

> Hi Mon Ping,
>
> Looks good; I like the iPTRAny idea. Comments below.
>
>>       // Print function.
>>       std::string OpVTStr;
>> -      if (OpVT == MVT::iPTR) {
>> +      if (OpVT == MVT::iPTR || OpVT == MVT::iPTRAny) {
>>         OpVTStr = "_iPTR";
>
> It probably doesn't break anything, but it seems a little confusing
> to have iPTRAny rendered as iPTR here. Could this print iPTRAny
> separately?
>
>> @@ -495,7 +496,8 @@
>>     setTypes(ExtVTs);
>>     return true;
>>   }
>> -  if (getExtTypeNum(0) == EMVT::isInt && ExtVTs[0] == MVT::iPTR) {
>> +  if (getExtTypeNum(0) == EMVT::isInt &&
>> +      (ExtVTs[0] == MVT::iPTR || ExtVTs[0] == MVT::iPTR)) {
>
> Looks like the second iPTR here should be iPTRAny.
>
>> @@ -527,6 +529,7 @@
>>   case EMVT::isFP : OS << ":isFP"; break;
>>   case EMVT::isUnknown: ; /*OS << ":?";*/ break;
>>   case MVT::iPTR:  OS << ":iPTR"; break;
>> +  case MVT::iPTRAny:  OS << ":iPTR"; break;
>
> As above, can iPTRAny be rendered as "iPTRAny"?
>
>> +      }
>> +    } else if (VT == MVT::iPTRAny) {
>> +      // Outside of TableGen, we don't distinguish iPTRAny (to any
> address
>> +      // space) and iPTR. In the verifier, we can not distinguish
> which case
>> +      // we have so allow either case to be legal.
>> +      if (const PointerType* PTyp = dyn_cast<PointerType>(Ty)) {
>> +        Suffix += ".p" + utostr(PTyp->getAddressSpace()) +
>> +        MVT::getMVT(PTyp->getElementType()).getMVTString();
>> +      }
>> +      else {
>
> Put the else on the same line with the } please :-).
>
> Thanks,
>
> Dan
>
> On Jul 25, 2008, at 3:51 PM, Mon P Wang wrote:
>
>> Hi,
>>
>> Here is an updated patch for intrinsic address space.  The effects
>> are the same.  The main difference between this patch and the other
>> one is that instead of assuming a pointer may or may not be
>> overloaded, I have introduced a new type iPTRAny which indicates
>> that the  pointer can be overloaded based on an address spaces.
>> This would allow us to overload intrinsics based only on a pointer.
>> The iPTRAny should only be used in TableGen (and part of the
>> Verifier)  and has the same semantics of iPTR except for the
>> overloading.  Please let me know if you have any comments.
>>
>>  -- Mon Ping
>>
>>
>> <addrspace4.patch>
>>
>>
>>
>> On Thu, July 17, 2008 3:56 pm, Mon P Wang wrote:
>>>
>>> Here is a patch to enable intrinsic to have pointers to different
>>> address spaces.  This changes overloaded intrinsics with pointer
>>> arguments to pass also an address space as part of their name.
>>>   For example,  atomic.load.add.i32 => atomic.load.add.i32.p0i32
>>>
>>> The above syntax indicates that the result is i32 with a pointer
>>> argument to address space 0 (generic address space) whose domain  
>>> type
>>> is i32.  The patch here doesn't include the documentation change but
>>> that will be included as part of the checkin.  Let me know if you
>>> have
>>> any comments.
>>>
>>> -- Mon Ping
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list