On Thu, 2007-05-17 at 22:57 -0400, John Anthony Kazos Jr. wrote: > Wouldn't the appropriate test be to demonstrate that the same program text > opcodes are generated in both cases for all architectures?
No, empirical testing with the compiler is never the _correct_ thing to do. It's just expedient. > If that's not the case, even if the generation isn't -worse-, it shows > that the compiler is doing different things with each, which means > different versions of the compiler could do different things with it, Well yes, but even it _is_ generating precisely the same output today, there's no reason why the compiler shouldn't behave differently under a different phase of the moon. The _correct_ thing to do is act upon my mutterings at the time I removed the '__attribute__((packed))' from various JFFS2 structures to improve the generated code on ARM -- actually implement an attribute for GCC which has the same "don't insert any padding" meaning, but without the unwanted "assume arbitrary alignment" implications. It'd actually be nice if GCC knew about endianness too. I don't want to have to do: *x = le32_to_cpu(cpu_to_le32(*x) + 5); I just want uint32_t __attribute__((littleendian)) *x; *x += 5; I know we can hack around it for masks, with '*x |= cpu_to_le32(X_BAR);' and such like, and we can load it into local native-endian variables and then copy it back again later -- but it's better just to let the compiler know what's going on and do its own optimisation. Especially on architectures which have 'load-and-swap' or 'store-and-swap' instructions. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
