>>> As for warning. I personally would argue that we are looking at >>> platform-specific i.e. implementation-defined behaviour, not undefined. >>> Once again, this applies to all three tickets. One is effectively >>> identical to this one, second is about variable shift in CAST. As >>> mentioned they all are conscious choices and are proven to work. > > I think Andy is right with respect to processor behavior. But I'm not > certain if its the best strategy given the C langauge rules.
What does it mean in practical terms? Would you a) resort to STRICT_ALIGNMENT at all occasions (arguing that performance benefits never worth it); b) accept compromise suggestion to adhere to STRICT_ALIGNMENT in debug-like build, in this case one with -DPEDANTIC? Fun fact in the context. If one defines STRICT_ALIGNMENT and gives the code to Clang, it actually generates code that relies on ... unaligned loads. I.e. it does exactly the kind of optimization that came under fire here. Yes, kind of double-standard: programmer is discouraged to utilize processor capability, while compiler does it :-) Well, in Clang's favour, it actually ends up doing better job, because it decides to use 16-byte loads instead of pairs of 8-byte ones as per C source code optimization. So that Clang users wouldn't have problem saying "a) [because I get the performance anyway]". In fact they can go as far as saying "define even OPENSSL_SMALL_FOOTPRINT [because I get same performance even then]". For reference, reaching for 16-byte loads is possible even from C, but with platform-specific extensions. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
