This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Clean up logic around aligned/sized allocation and deallocation
ClosedPublic

Authored by ldionne on Sep 25 2020, 6:42 AM.

Details

Summary

Due to the need to support compilers that implement builtin operator
new/delete but not their align_val_t overloaded versions, there was a
lot of complexity. By assuming that a compiler that supports the builtin
new/delete operators also supports their align_val_t overloads, the code
can be simplified quite a bit.

Diff Detail

Event Timeline

ldionne created this revision.Sep 25 2020, 6:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 25 2020, 6:42 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne requested review of this revision.Sep 25 2020, 6:42 AM
ldionne added a subscriber: EricWF.

This should be NFC (except it means that Clangs older than 201802L are not supported anymore). @EricWF I would love if you could take a look.

ldionne updated this revision to Diff 294318.Sep 25 2020, 8:15 AM

Rebase onto master to try to get pre-commit testing

I don't think this patch makes sense given D87611. @Kai, @fanbo-meng, @abhina.sreeskantharajan, @zibi, fya.

<stdin>:6:3: error: aligned allocation function of type 'void *(unsigned long, enum std::align_val_t)' is not available on z/OS
  __builtin_operator_new(sizeof(int), static_cast<std::align_val_t>(16));
  ^

I don't think this patch makes sense given D87611. @Kai, @fanbo-meng, @abhina.sreeskantharajan, @zibi, fya.

<stdin>:6:3: error: aligned allocation function of type 'void *(unsigned long, enum std::align_val_t)' is not available on z/OS
  __builtin_operator_new(sizeof(int), static_cast<std::align_val_t>(16));
  ^

I think it does. The issue is that we're not detecting _LIBCPP_HAS_NO_ALIGNED_ALLOCATION properly.

That macro is defined as:

#if !defined(_LIBCPP_HAS_NO_ALIGNED_ALLOCATION) && \
    (defined(_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION) || \
    (!defined(__cpp_aligned_new) || __cpp_aligned_new < 201606))
#  define _LIBCPP_HAS_NO_ALIGNED_ALLOCATION
#endif

What is __cpp_aligned_new set to on z/OS?

I think it does. The issue is that we're not detecting _LIBCPP_HAS_NO_ALIGNED_ALLOCATION properly.

Thanks for the quick response. I was checking whether or not Clang reliably has the aligned builtin operator new based on my reading of the patch description:

excerpt:

By assuming that a compiler that supports the builtin new/delete operators also supports their align_val_t overloads, the code can be simplified quite a bit.

If libc++ still checks __cpp_aligned_new, then the patch should be okay.

What is __cpp_aligned_new set to on z/OS?

It's not defined. The detection for _LIBCPP_HAS_NO_ALIGNED_ALLOCATION should work okay.

zibi added a comment.Sep 25 2020, 12:45 PM

What is __cpp_aligned_new set to on z/OS?

It's not defined. The detection for _LIBCPP_HAS_NO_ALIGNED_ALLOCATION should work okay.

Yes its not defined however, with -std=c++17 _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined on z/OS.

zibi added a comment.Sep 25 2020, 2:14 PM

That macro is defined as:

#if !defined(_LIBCPP_HAS_NO_ALIGNED_ALLOCATION) && \
    (defined(_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION) || \
    (!defined(__cpp_aligned_new) || __cpp_aligned_new < 201606))
#  define _LIBCPP_HAS_NO_ALIGNED_ALLOCATION
#endif

What is __cpp_aligned_new set to on z/OS?

The __cpp_aligned_new is defined as 201616 on z/OS. However, z/OS will define _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION explicitly and both macros '_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION and _LIBCPP_HAS_NO_ALIGNED_ALLOCATION will be defined. That is one of the upcoming change or you can do it here as I suggested on line 948 in __config.

libcxx/include/__config
951

`# define _LIBCPP_HAS_NO_ALIGNED_ALLOCATION
#elif defined(MVS)

  1. define _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION`
ldionne updated this revision to Diff 294811.Sep 28 2020, 2:49 PM

Rebase onto master

ldionne accepted this revision as: Restricted Project.Oct 9 2020, 9:50 AM
This revision was not accepted when it landed; it landed in state Needs Review.Oct 9 2020, 9:51 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.