[SYCL] Added missing SYCL 2020 USM features

[dnmokhov]

• USM atomic allocation aspects (+ tests)
• handler::mem_advise
• handler::copy and queue::copy
• queue class: overloads of fill, memset, memcpy, copy, mem_advise, prefetch with dependency event arguments
• optional property list argument in USM allocation functions and usm_allocator constructors (+ tests)

Tests: intel/llvm-test-suite#342

[dnmokhov]

/summary:run

[cperkinsintel]

other than the question, LGTM.

[dnmokhov]

Pinging the reviewers: @intel/llvm-reviewers-runtime , @s-kanaev, @jbrodman, @dm-vodopyanov.

[vladimirlaz]

@dnmokhov could you add tests for newly added functionality to https://github.com/intel/llvm-test-suite/
If it is in place please add link to the PR description.

[cperkinsintel]

LGTM

[s-kanaev]

LGTM

[gmlueck]

I noticed that this change was just merged.

Coincidentally, the language evolution group just identified a spec bug here. The USM copy member functions take the src and dst parameters in the wrong order. The order should be (src, dst), which matches the standard C++ copy function and matches the existing SYCL copy functions that take accessor parameters.

Can we change the implementation of these USM copy member functions?

[cperkinsintel]

@gmlueck - is that right? memcpy is definitely dest pointer argument first, followed by source. I thought std::copy took iterators, not pointers. The sycl::memcpy and sycl::copy methods in this PR both take pointers, no? Perhaps it's not the order of the arguments the committee should discuss, but the naming of the sycl::copy function?

[gmlueck]

We agree that std::memcpy is (dst, src), so we do not think the USM memcpy functions should change. They should remain as they are with (dst, src) ordering.

The USM copy functions are the ones we're worried about, which also have the parameter order (dst, src). Our primary concern is that this does not match the parameter order for the handler::copy() member functions that take an accessor parameter. Those functions have (src, dst) ordering. We think it is particularly bad to have two overloads of the handler::copy() function, where one takes (src, dst) and the other takes (dst, src).

We also think that the (src, dst) ordering is consistent with std::copy(). You are correct that std::copy() takes iterators (not pointers) as parameters. However, the order of the iterators is "src" first and then "dst".