Add memory semantics to atomic builtins

[MrSidims]

It's deduced from a pointer's address space.
Resolves:
#3371

[MrSidims]

@svenvh @bashbaug Tests are currently failing, but if we are good with the approach - I'll investigate and fix the failures.

[svenvh]

@svenvh @bashbaug Tests are currently failing, but if we are good with the approach - I'll investigate and fix the failures.

The approach looks reasonable to me; it would be nice to have some comments on the various functions though (explaining for which cases we need getAddressSpaceFromValue for example).

[bashbaug]

The overall approach LGTM, thanks!

[bashbaug]

For my own understanding, is this kind of a "light" form of generic addresss space inference?

Is this primarily needed because explicit address space overloads don't exist, or because explicit address space overloads aren't being used, or something else?

To be clear, I think this is fine and a good idea to include, just trying to understand why it is needed.

[MrSidims]

Yes, it's light version of Infer Address Space pass. It's created because different front ends can pick different default address spaces for pointers. AFAIK even for upstream OpenCL there will be different LLVM IR produced by clang for SPIR and AMDGPU (through SPIR(V) tool chain(s) targets).

I'm actually missing one assumption. If worklist ends up on generic alloca - it should be assumed as private alloca.