[SERVER-38462] Evaluate safety of abseil's unaligned access mechanisms Created: 07/Dec/18  Updated: 29/Oct/23  Resolved: 07/Jan/19

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: 4.1.7

Type: Task Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: Billy Donahue
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Dev Tools 2018-12-31, Dev Tools 2019-01-14
Participants:

 Description   

Abseil has some fun deciding how and when to use unaligned operations. Notably, it does them, but then pretends it doesn't if it knows certain sanitizers are active. Otherwise, it tries some hardware assumptions and then falls back to memcpy. Of course memcpy is actually the right answer, in a strict sense. We should take a look to decide whether we trust abseils choices here or whether we want to force to memcpy.



 Comments   
Comment by Githook User [ 07/Jan/19 ]

Author:

{'username': 'BillyDonahue', 'email': 'billy.donahue@mongodb.com', 'name': 'Billy Donahue'}

Message: SERVER-38462 disable the ABSL internal use of reinterpret_cast for unaligned access
Branch: master
https://github.com/mongodb/mongo/commit/de4f60966b2ea5f461ba532edda65c560002140d

Comment by Githook User [ 20/Dec/18 ]

Author:

{'username': 'BillyDonahue', 'email': 'billy.donahue@mongodb.com', 'name': 'Billy Donahue'}

Message: SERVER-38462: add ifdef for ABSL_FORCE_ALIGNED_ACCESS
Branch: master
https://github.com/mongodb/mongo/commit/3655cebb44ef6249c8d1654f860bbb0c13fd8bb5

Comment by Billy Donahue [ 20/Dec/18 ]

Benchmark on the effect of ABSL_FORCE_ALIGNED_ACCESS on the insertion speed of Flat and Node hash maps.
https://docs.google.com/spreadsheets/d/155pgCRPpECXEIF9v8zXyg5jyb1s4Q1cxt2Xs8Z4YTyc/edit?usp=sharing

Comment by Githook User [ 19/Dec/18 ]

Author:

{'username': 'BillyDonahue', 'email': 'billy.donahue@mongodb.com', 'name': 'Billy Donahue'}

Message: SERVER-38462 just apply all of patches/*.patch. Update abseil revision.

SERVER-38462: add ifdef for ABSL_FORCE_ALIGNED_ACCESS

add forgotton absl new files

Revert "SERVER-38462: add ifdef for ABSL_FORCE_ALIGNED_ACCESS"

This reverts commit f7f51c062ceb23d6b5395d4fce75b3e4e0b9ddff.
Branch: master
https://github.com/mongodb/mongo/commit/1a0d01a2d8ca27934bceb1bd65643915a1cca17a

Comment by Billy Donahue [ 19/Dec/18 ]

Code review url: https://mongodbcr.appspot.com/230510001

Comment by Billy Donahue [ 19/Dec/18 ]

It should be "force aligned access". They have a macro with a similar meaning that is misnamed ABSL_INTERNAL_NEED_ALIGNED_LOADS

I was copying its bad name. But I shouldn't. It's an internal name anyway and mine isn't.

Comment by Andrew Morrow (Inactive) [ 19/Dec/18 ]

I like that idea. Lets try to propose it to upstream too. Is it just for loads, or stores too? ABSL_FORCE_ALIGNED_ACCESS?

Comment by Billy Donahue [ 18/Dec/18 ]

I'm going to add in an ABSL_FORCE_ALIGNED_LOADS macro to bypass the optimizations for the common case that one cares more about portable correctness than about missed optimization opportunities due to late-stage inlining.

Comment by Billy Donahue [ 18/Dec/18 ]

I'm looking at absl/base/internal/unaligned_access.h.
The #ifdef tree for accepting UB here is dependent only on architecture macros, not compiler.
It seems an architecture can't be considered safe or unsafe without regard to which compiler is emitting code for it.

It includes the following note:

// Portable handling of unaligned loads, stores, and copies.
// On some platforms, like ARM, the copy functions can be more efficient
// then a load and a store.
//
// It is possible to implement all of these these using constant-length memcpy
// calls, which is portable and will usually be inlined into simple loads and
// stores if the architecture supports it. However, such inlining usually
// happens in a pass that's quite late in compilation, which means the resulting
// loads and stores cannot participate in many other optimizations, leading to
// overall worse code.

Generated at Thu Feb 08 04:49:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.