On Oct 18, 2011, at 3:25 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 10/18/2011 06:07 PM, Jakub Jelinek wrote: >> On Tue, Oct 18, 2011 at 06:03:16PM -0400, Andrew MacLeod wrote: >>> Here's the last of the missing intrinsics. compare_exchange is >>> slightly different than the others since it doesn't map directly to >>> an rtl pattern. Its format is : >>> >>> bool __atomic_compare_exchange (T* mem, T* expected, T desired, >>> bool weak, memory_order success, memory_order failure) >>> >>> note that the expected parameter is a pointer as well. In the case >>> where false is returned, the value of expected is updated. >> I think the __sync_* way here was much better (two intrinsics instead of >> one, one bool-ish and one returning val). With mandating T*expected >> you force it to be addressable, probably until expansion time at which point >> it will be just forced into memory, which is highly undesirable. >> > > Its impossible to implement a weak compare and swap unless you return both > parameters in one operation.
In my port, we have support in our built-in processor to have 0 or more outputs for built-ins. Not terribly hard to wire up and do. We support doing it as a c++ style reference parameter, aka a pointer to memory, for those things that can be expressed as addresses, and as a real lvalues, so that you can have register outputs as well. Inside code-gen, for the later case, we dummy up a structure, and spill things to memory, then load up all the outputs from memory, the idea being that the optimizer should be able to remove the spills; worst case I think is we might have to put on unique tags for all the memory accesses so they never conflate with normal loads and stores, though, we've not yet bothered to see if we need to yet. All this space is stack based, so, should be easy to analyze. One style of instruction we find the flexibility useful for are cas style instructions. With the processor, describing the built-ins is fairly easy, as is describing how they bind to rtl. >
