P1007R3 assume_aligned()

[StephanTLavavej]

P1007R3 assume_aligned()

This needs support from the compiler back-end, tracked by Microsoft-internal VSO-917620.

Feature-test macro as of WG21-N4842, added by WG21-P1902:
#define __cpp_lib_assume_aligned 201811L

[AlexGuteniev]

Is this still blocked?

[CaseyCarter]

Is this still blocked?

No it is not. C1XX and Clang (and EDG, I think?) support __builtin_assume_aligned, assume_aligned is sitting latent in <memory>:

STL/stl/inc/memory

Lines 2947 to 2955 in 212de15

	#if _HAS_CXX20 && 0
	template <size_t _N0, class _Ty>
	_NODISCARD constexpr _Ty* assume_aligned(_Ty* _Ptr) noexcept /* strengthened */ {
	// this enforces the requirement that _N0 be a power of two
	__builtin_assume_aligned(_Ptr, _N0);
	return _Ptr;
	}
	#endif // _HAS_CXX20 && 0

waiting for someone to finish up the work. (Noted in passing: _N0 is not a great template parameter name since it's in the _RESERVED_MACRO_IDENTIFIER space.)

[AlexGuteniev]

Aha, so is it Good First Issue now?

[CaseyCarter]

Aha, so is it Good First Issue now?

More of a Good First Feature. "Good First Issue" is meant for things that are as simple and straightforward as possible - "Change these lines: .... to this: ..." - where the challenge comes from learning the engineering system. "Good First Issues" are loss leaders in that they take a maintainer more time to write up than they would to fix, but they hopefully make it easier to bring more maintainers into the fold.

This issue, however, is more "enable the function, fix the parameter name that Casey doesn't like, whip up a smoke test, investigate if there's a feature-test macro to define and add the proposal to the list of C++20 stuff in yvals_core.h". It's no "Timezones and Calendars," but still a few steps above "Update _MSVC_STL_VERSION".

[StephanTLavavej]

I'll fix up the _N0 problem throughout stl/inc.

[AlexGuteniev]

I don't see __builtin_assume_aligned works.

I mean it is accepted by the compiler, but does not affect code generation.

[AlexGuteniev]

Ah, anyway you test in debug mode with /Od, so it cannot be tested.

I though the test is as follows:

• Have a routine that does something simple, like integer sum - with __builtin_assume_aligned and without it.
• Pass aligned and unaligned pointer, where its origin is erased via volatile global variable.
• Only unaligned pointer on __builtin_assume_aligned throws SEH exception, other do not throw.

But I get aligned codegen optimization only if I pass something that has non-erased alignas.

[StephanTLavavej]

I don't think we should test what happens if we violate the intrinsic's preconditions (i.e. pass an unaligned pointer). A basic test should ensure that we can pass a properly aligned pointer, do a little work with it, and everything behaves as expected. We can compile with /O2 for that, although that's almost never used in the STL's tests. (I'd have to look up whether our launder test found the compiler bug under /O2, or whether it happened even under /Od.)

Whether the optimizer takes advantage of this information, and in what situations, seems out of scope for the STL's test suite (i.e. it is perfectly reasonable to manually test and report bugs on Developer Community).

[AlexGuteniev]

I've reported DevCom-1121352 already, now I discovered even better case towards compiler shouldn't ignore this hint, added it as a comment there. Apparently a good std feature will be underimplemented without the proper compiler support.