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.mar...@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
>
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
