In general the product should move forward and drop work-arounds like -mimplicit-it. We (the greater ARM community) should fix these package problems as they are found. Here's a bunch of quick-fire statements:
* Qt is currently broken on ARM multiprocessor systems * Qt provides a QAtomic class which provides atomic functions on integers and pointers * You can call different functions depending on your ordering constraints * GCC's __sync primitives are ordered only * The ARMv6 QAtomic implementation only provides ordered versions * AVR32 currently uses the sync primitives in the same way
So there's a precedent there for __sync primitives and they'd be equivalent to what is already there. If RVDS also supports __sync_* (Richard?) then we can also delete the RVDS specific code.
The kernel adds -mimplicit-it via its own build rules. What else needs -mimplicit-it? Matthias, are you running a rebuild at the moment? How many extra packages have failed?
I had a play with the Maverick GCC-4.5 and binutils. This code:
void foo() { asm("it eq\n\t" "teqeq r2,#1" ); }
compiles fine with -marm, -mthumb, and -march=armv4t -marm. It seems the assembler accepts IT instructions in both unified and compatibility modes.
-- Michael
On Sat, Nov 13, 2010 at 6:33 AM, Dave Martin dave.martin@linaro.org wrote:
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