[PATCH] Support for builtins __sync_fetch_and_nand and __sync_nand_and_fetch

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Support for builtins __sync_fetch_and_nand and __sync_nand_and_fetch

Wesley Peck-2
Attached is a patch that adds support for the builtin functions __sync_fetch_and_nand and __sync_nand_and_fetch. It lowers the builtins to the associated LLVM intrinsic function.

--
Wesley Peck
University of Kansas
SLDG Laboratory




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

clang_sync_nand.patch (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Support for builtins __sync_fetch_and_nand and __sync_nand_and_fetch

Wesley Peck-2
As a note, I just now noticed commit 99522 which removed these operations because they are inconsistently implemented in GCC. I believe the problem is GCC before 4.4 implemented:

res = ~(*mem) & val

where as GCC 4.4 and after implement:

res = ~(*mem & val) 

Is this still an issue? The patch that I attached implements the form used by GCC 4.4 and later for __sync_nand_and_fetch and simply lowers to the LLVM intrinsic function for __sync_fetch_and_nand.

--
Wesley Peck
University of Kansas
SLDG Laboratory

On Dec 21, 2010, at 4:06 PM, Wesley Peck wrote:

Attached is a patch that adds support for the builtin functions __sync_fetch_and_nand and __sync_nand_and_fetch. It lowers the builtins to the associated LLVM intrinsic function.

--
Wesley Peck
University of Kansas
SLDG Laboratory

<clang_sync_nand.patch>



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Support for builtins __sync_fetch_and_nand and __sync_nand_and_fetch

Dale Johannesen

On Dec 21, 2010, at 2:18 PM, Wesley Peck wrote:

As a note, I just now noticed commit 99522 which removed these operations because they are inconsistently implemented in GCC. I believe the problem is GCC before 4.4 implemented:

res = ~(*mem) & val

where as GCC 4.4 and after implement:

res = ~(*mem & val) 

Yes.  IIRC I was the one who decided to follow 4.2 in llvm even though it was, IMO, wrong; I wasn't comfortable with that choice, but incompatibility is bad too.  Since this has been disabled for 9 months without anyone complaining it should be safe to go ahead and do it right at this point.   Just MO.

Is this still an issue? The patch that I attached implements the form used by GCC 4.4 and later for __sync_nand_and_fetch and simply lowers to the LLVM intrinsic function for __sync_fetch_and_nand.

--
Wesley Peck
University of Kansas
SLDG Laboratory

On Dec 21, 2010, at 4:06 PM, Wesley Peck wrote:

Attached is a patch that adds support for the builtin functions __sync_fetch_and_nand and __sync_nand_and_fetch. It lowers the builtins to the associated LLVM intrinsic function.

--
Wesley Peck
University of Kansas
SLDG Laboratory

<clang_sync_nand.patch>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Support for builtins __sync_fetch_and_nand and __sync_nand_and_fetch

Chris Lattner

On Dec 21, 2010, at 2:30 PM, dalej wrote:

>
> On Dec 21, 2010, at 2:18 PM, Wesley Peck wrote:
>
>> As a note, I just now noticed commit 99522 which removed these operations because they are inconsistently implemented in GCC. I believe the problem is GCC before 4.4 implemented:
>>
>> res = ~(*mem) & val
>>
>> where as GCC 4.4 and after implement:
>>
>> res = ~(*mem & val)
>
> Yes.  IIRC I was the one who decided to follow 4.2 in llvm even though it was, IMO, wrong; I wasn't comfortable with that choice, but incompatibility is bad too.  Since this has been disabled for 9 months without anyone complaining it should be safe to go ahead and do it right at this point.   Just MO.

Wesley, is there any reason to add these?  Given the option, I'd rather delay adding these for as long as possible... and when/if we really need to add them, follow the obvious definition that mainline gcc switched to.  The reason to not add them is in the intermediate transition point: not having them forces people that use them to be aware of this.

Another way to handle this is to add a new name for the same operation.

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Support for builtins __sync_fetch_and_nand and __sync_nand_and_fetch

Wesley Peck-2
On Dec 21, 2010, at 7:51 PM, Chris Lattner wrote:
> Wesley, is there any reason to add these?

Not really. I originally worked up the patch just because I noticed the nand operations were missing while I was working on adding support for atomics to the MBlaze backend.

I've created a bug report (8842) to track the status of these two atomic builtins. Hopefully, this will make the status more clear to Google users.
 
--
Wesley Peck
University of Kansas
SLDG Laboratory
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Support for builtins __sync_fetch_and_nand and __sync_nand_and_fetch

Chris Lattner
Sounds great, thanks!

On Dec 21, 2010, at 6:26 PM, Wesley Peck wrote:

> On Dec 21, 2010, at 7:51 PM, Chris Lattner wrote:
>> Wesley, is there any reason to add these?
>
> Not really. I originally worked up the patch just because I noticed the nand operations were missing while I was working on adding support for atomics to the MBlaze backend.
>
> I've created a bug report (8842) to track the status of these two atomic builtins. Hopefully, this will make the status more clear to Google users.
>
> --
> Wesley Peck
> University of Kansas
> SLDG Laboratory


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev