Hi Richard, Recapping on this earlier conversation:
http://lists.linaro.org/pipermail/linaro-toolchain/2010-July/000030.html http://lists.linaro.org/pipermail/linaro-toolchain/2010-July/000035.html Is it worth another attempt to make a case to upstream for supporting passing -mimplicit-it=thumb by default to gas? According to my understanding of this issue, my argument would go as follows: * gcc currently estimates the size of asm blocks, rather than determining the size accurately. * gcc cannot guarantee the right answer for asm block size when asm blocks contain directives etc., however use of directives in asm blocks is widespread * gcc cannot guarantee the right answer for asm block size in Thumb-2. gcc conservatively overestimates the size by assuming that each statement of the asm block expands to 4 bytes. * All of Ubuntu lucid and maverick has been built with -mimplicit-it=thumb passwd by default, with no known build or runtime failures arising from this (so size issues aside, we have confidence that the resulting code generation is sound) * -mimplicit-it=thumb -mthumb makes the asm block size estimation unsafe: the asm block can exceed the estimated size even in the absence of directives, which may lead to fixup range errors during assembly. * Following the principles already established for Thumb-2 in general the estimation can be made safe (or, as safe as the established Thumb-2 behaviour) by raising the assumed maximum statement expansion size for asm blocks to 6 bytes, since -mimplicit-it will add as most a single (16-bit) IT instruction to each statement. * The vast majority of all asm blocks are small (< 20 instructions, say), so the overall overestimate in sizes will generally be modest for any given compilation unit. * -mimplicit-it is already _required_ by the Linux kernel and possible other projects. ...so... * With -mimplicit-it=thumb and a 6-byte asm block statement expansion size estimate, we have toolchain behaviour which is as reliable, and as correct, as it is in upstream at present. * Layout of data in the compiler output will be more optimal in some cases, and less optimal in other cases, compared with the the current Thumb-2 behaviour, due to differing asm block size estimates. The exact behaviour will depend on the distribution of conditional instructions within asm blocks. * Taken over a whole compilation unit, the total code size overestimate (and therefore the impact on object layout) will normally be modest, due to the small typical size of asm blocks. * Behaviour for -marm will not be impacted at all. If gcc currently estimated asm block code size accurately, then I could understand upstream's objection; but as it stands it seems to me we wouldn't be making anything worse in practice with the proposed change; and there is no compatibility impact (other than positive impact). Of course, I may have some wrong assumptions here, or there may be some background I'm not aware of... Comments? Cheers ---Dave _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
