[Libclc-dev] Questions about atomics

[Aaron Watry]

Hi Jeroen,

I actually just committed atomic_sub and atomic_dec support yesterday :)

The libclc support was waiting to be added in libclc due to missing
support for the relevant instructions in the llvm R600 back-end.  I
finally committed that support to llvm yesterday, and then immediately
after, I pushed the libclc support.

With regards to the _addr* naming.  The R600 back-end uses address
space 1 as global, 2 is constant, 3 is local, and private is either 0
or 4 (I obviously haven't used that one much).

By defining the generic functions in terms of address space 1/2/3/4,
we just have to write the assembly functions once, and then we just
have to map which named address space is which ID on various hardware
back-ends.  Hence the split for the implementations in generic/ and
the mappings defined in r600/.  Theoretically, if we wanted to then
add Nvidia/Intel/X86 support for a given function, we'd just have to
map the correct implementation to the numbered address space needed.

Hope that helps,
Aaron

On Fri, Sep 6, 2013 at 8:54 PM, Jeroen Ketema <j.ketema at imperial.ac.uk> wrote:
>
> Hi,
>
> I was looking at the code for atomics that was committed in the last two days and I'm wondering about two things. First, is there a reason that atomic_sub is not introduced in the r600 code (atomic_add is there)? Second, why is atomic_add only defined as the generic @__clc_atomic_add_addr… in the r600 code (since @__clc_atomic_add_addr… occurs in the generic code I expect the definition of atomic_add to be there too)?
>
> Thanks,
>
>  Jeroen
>
>
> _______________________________________________
> Libclc-dev mailing list
> Libclc-dev at pcc.me.uk
> http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev