Hi, > I would go with option 2. and detect the ARM architecture that we are > compiling for in the configure phase and compile for it.
As mentioned in another message question was not about removing run-time switch as concept, but about limiting it to ARMv>=7 targets. > My gut feeling is that it is better not to have extra stuff in the > binary. When you compile for the specific > architecture, you get a tighter, more simple binary, with no extra > unused execution paths. If the wrong ARM architecture > code path were to somehow be executed, undefined behaviour could > happen. SIGILL crashes, for example. I hear you and do recognize that limiting yourself only to executable paths has own value. But life is compromise and I reckon that run-time switch in *assembly* is reasonable one, because we have very fine control over which instructions are used. Yes, there will be some dead code from some processor viewpoint, but remaining one is guaranteed to execute. "Guaranteed" means that if it doesn't, it will be treated as bug and will be fixed. [Naturally with exception for feature detection discussed in FAQ#17 in "programming" section.] > Also the compiler can optimize the C parts for the architecture as > well. I remember accidentally running a color conversion library > written in C compiled for Cortex A15 on an A9, and got a crash with > SIGILL. So the output is different. When I disassembled it, I could > see it was using some new instruction combinations, compared with the > A9 binary I then made. Anyhow, you are likely to see some performance > increases in the C parts that are not written in assembly or > neon-optimized when compiling for specific architectures. Option #1 naturally implies that you'll sacrifice some performance, but idea is that it will be compensated for, because most critical parts are implemented in assembly. Thanks for feedback. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
