This is an archive of the discontinued LLVM Phabricator instance.

[mlir] move _mlir_alloc and friends to CRunnerUtils
ClosedPublic

Authored by ftynse on Jul 18 2022, 9:29 AM.

Details

Summary

These functions don't depend on the C++ runtime and therefore belong to
CRunnerUtils. Clean up the macros on the way as _MSC_VER indicates the
compiler, not the platform, which is indicated by _WIN32 and will be
present when, e.g., compiling with minGW.

Diff Detail

Event Timeline

ftynse created this revision.Jul 18 2022, 9:29 AM
ftynse requested review of this revision.Jul 18 2022, 9:29 AM
rdzhabarov accepted this revision.Jul 18 2022, 9:32 AM
This revision is now accepted and ready to land.Jul 18 2022, 9:32 AM
mscuttari added a comment.EditedJul 18 2022, 9:35 AM

I was unsure where to put those functions inside the runtime library, so it's perfectly fine for me to move them.
I'm unsure about the _WIN32 macro though, the usage of _MSC_VER was caused by the fact that MSVC's implementation of the standard library doesn't provide the aligned_alloc function, despite it being part of the standard. Instead, it provides an _aligned_malloc function. Moreover, MSVC also requires the pointers obtained through _aligned_malloc to be deallocated through _aligned_free, and not free (it doesn't impact the previous reasoning, but better to make it known)

I was unsure where to put those functions inside the runtime library, so it's perfectly fine for me to move them.
I'm unsure about the _WIN32 macro though, the usage of _MSC_VER was caused by the fact that MSVC's implementation of the standard library doesn't provide the aligned_alloc function, despite it being part of the standard. Instead, it provides an _aligned_malloc function. Moreover, MSVC also requires the pointers obtained through _aligned_malloc to be deallocated through _aligned_free, and not free (it doesn't impact the previous reasoning, but better to make it known)

Hmm, should we then guard by a conjunction of both macros?

mscuttari added a comment.EditedJul 18 2022, 9:46 AM

Yes, that wouldn't hurt. I feel like the _WIN32 macro alone, though, would cause problems.
I understand that the MSVC macro is not the best in term of maintenability, but unfortunately this is the situation. Here is a link to the official docs for what regards _aligned_malloc and _aligned_free: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/aligned-malloc

Side question, as these are my first times dealing with Phabricator: where do I find the option to accept the revision when I'm among the reviewers?

FWIW, from the mingw point of view, this patch seems fine - mingw doesn’t yet provide the standard aligned_alloc either, but _aligned_malloc can be used, just like with MSVC. So therefore, using _WIN32 for the ifdef seems fine.

This revision was landed with ongoing or failed builds.Jul 25 2022, 6:53 AM
This revision was automatically updated to reflect the committed changes.