[llvm] [libsycl] USM Aligned allocation functions (PR #213468)
via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 24 07:32:43 PDT 2026
================
@@ -103,14 +154,29 @@ void *malloc(std::size_t numBytes, const device &syclDevice,
void *Ptr{};
auto OLDevice = detail::getSyclObjImpl(syclDevice)->getOLHandle();
- auto Result =
- kind == usm::alloc::host
- ? detail::callNoCheck(olMemAllocHost, OLDevice, numBytes, &Ptr)
- : detail::callNoCheck(olMemAlloc, OLDevice,
- detail::getOlAllocType(kind), numBytes, &Ptr);
+ auto Result = kind == usm::alloc::host
+ ? detail::callNoCheck(olMemAllocAlignedHost, OLDevice,
----------------
Robertkq wrote:
Ok.. so I have a follow up just so it's clearer for me in which way to take development
Throughout the code, as you also noted, I have certain `modifications` of alignment argument, that tries to address [Alignment guarantees of USM allocation functions ](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_usm_allocations)
I believe that if we were to fully support this, which I don't necessarily see why not, we could use only the `aligned` versions of `olMemAlloc` for USM functions, because all types of allocations need guarantees which can be explicitly satisfied with `olMemAllocAligned` rather than implicitly with `olMemAlloc`
If possible, can you suggest a path I should go ahead for the implementation with?
I could rather:
1. Remove explicit alignment guarantees & all memory allocations requested with 0 alignment will call `olMemAlloc`
> This option make use of more `offload` API which could be "clearer", but we implicitly rely on liboffload for alignment guarantees
2. Add necessary guarantees to also satisfy row 3 of Table n. 70, keep routing everything via `olMemAllocAligned`, `aligned_alloc` will always have alignment ` != 0` by the time it reaches it's last overload, even if user called with `0`, it will change to minimum guarantee
> I believe this option gives us explicit guarantees to conform to SYCL specs
Hope I understood well and the question is well formed
https://github.com/llvm/llvm-project/pull/213468
More information about the llvm-commits
mailing list