John Regehr@regehr@mastodon.social
I like this Rob Pike piece. I recall seeing criticism of it but I forgot the details. is the problem that doing things Rob's way can be too slow?
https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html
John Regehr@regehr@mastodon.social
Billy O'Neal@malwareminigun@infosec.exchange
@regehr@mastodon.social If it could be too slow that could be addressed with a function to do exactly this optimizers understand... oh hello there htonl.
ori@ori@hj.9fs.net
Optimizers also understand the shift and or pattern, and optimize it to a bswap instruction.
CC: @regehr@mastodon.social
Billy O'Neal@malwareminigun@infosec.exchange
@ori@hj.9fs.net @regehr@mastodon.social only in release builds, and even then you kinda just have to pray that nothing else in the area causes it to not recognize the pattern, and hope that order dependencies between optimization passes don't cause suboptimal behavior elsewhere. If the part of your program doing this isn't somewhere where throughput matters toooooooo much, then sure, so the portable solution.
For example, LLVM runs its optimizer a given number of times, so sometimes patterns it can handle in small examples don't work so well in a full program. For example https://youtu.be/s4wnuiCwTGU
For example, MSVC's inliner is a relatively early pass, so you can get cases where it thinks a function is a bad inline candidate for being too big and doesn't even if later passes make it one. This is why our STL has Passfn to avoid during function*&