> (+ Andy) > > ... >> >> Looking at the generated code, I see references to __ARMEB__ and > __ILP32__. >> The former is probably a bug, Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__! Apparently I simply went on assuming that it would be __ARMEB__/__ARMEL__ even in 64-bit case. As Ard mentioned, there is a number of modules that can be compiled for either 32- or 64-bit case, and supposedly that's where this blunder stems from. Will fix... As for it being actually tested. No, I don't have big-endian AArch64 setup, and big-endian segments in AArch64 are based on experience with endian neutrality elsewhere. I.e. it's based on observations what it takes to achieve the neutrality elsewhere, e.g. ARM, MIPS, PPC, and then exercising equivalent approach even here. Modulo fact that I apparently got macros wrong :-( >> whilst the second is not required. Note that references to __ILP32__ are also inside #ifndef __KERNEL__/#endif, i.e. they won't be even evaluated when compiled for kernel. Or in other words it's shared code artefact just like #if[n]def __KERNEL__ itself. You either disregard it or remove altogether, but then code becomes specific and not shared :-) >> There are >> also some commented out instructions, which is weird. Commented instructions denote those that are moved into next round in order to improve instruction scheduling on either of processors. In other words it means that you should spot it further below [in generated code]. Yes, it's weird, but it helps me to remember which instructions are moved. On side note it's not uncommon that instruction scheduling is result of compromise. In general I attempt to schedule instruction for near-optimal performance on *multiple* processors, but sometimes you have to make compromises. One is mentioned in commentary section for this very module, the Apple A7 vs. Cortex-A53 thing. Well, it's not like the commented instruction you're observing is the only result of the compromise, it's merely an example of how said compromises can manifest themselves, as somewhat weird irregularities in the code, possibly with commented instructions. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
