RFC: -mimplicit-it and GCC upstream
dave.martin at linaro.org
Mon Nov 22 10:35:13 UTC 2010
On Wed, Nov 17, 2010 at 11:22 AM, Dave Martin <dave.martin at linaro.org> wrote:
> On Wed, Nov 17, 2010 at 2:53 AM, Michael Hope <michael.hope at 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
* -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.
More information about the linaro-toolchain