On Wed, Nov 17, 2010 at 11:22 AM, Dave Martin <dave.mar...@linaro.org> wrote: > On Wed, Nov 17, 2010 at 2:53 AM, Michael Hope <michael.h...@linaro.org> wrote: >> 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
[...] Having discussed this further with Richard, it sounds like there are enough issues blocking -mimplicit-it upstream that we should not expect it to be supported by default upstream in the foreseeable future: * -mimplicit-it disables some important sanity-checking on the compiler output (by not checking compiler-generated ITs, or the absence thereof). We could in principle make the assembler only inject ITs in between #APP and #NO_APP, but the assembler doesn't support this yet; nor does any arm gcc I've seen systematically generate these directives for inline asms; so implementing this would probably result in a flag day when everyone has to move to up-to-date gcc and gas. Upstreams are unlikely to go for that. * with -mimplicit-it, the compiler must be pretty conservative about inline asm block size (assuming 6 byte per statement) - that's feasible, but very suboptimal and is likely to result in the need for yet another compiler option to turn it on; again, this is unlikely to become the default upstream. * add-hoc workarounds can be used, such as wrapping GCC to compile in multiple passes so that the correct inline asm size for each block can be determined. But such approaches are likely to be too cumbersome to get merged in any project. So I've now come round to the view that we _should_ probably bite the bullet and fix the inline asm directly. So: * We need to verify which binutils permit (and ignore) the IT instructions in non-unified (ARM) syntax. I've observed that 2.19.1 definitely supports this; I don't know about earlier versions -- this is probably something the toolchain group should investigate. * We should be proactive about making these changes upstream. Writing some standard wording to explain the reason for the change and the likely impact would probably be a good idea. Cheers ---Dave _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
