Date:	Wed, 02 Feb 2011 11:14:45 -0800
From:	Ian Lance Taylor <iant@...gle.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	Peter Maydell <peter.maydell@...aro.org>, gcc@....gnu.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ulrich Weigand <Ulrich.Weigand@...ibm.com>
Subject: Re: ARM unaligned MMIO access with attribute((packed))

Arnd Bergmann <arnd@...db.de> writes:

> On Wednesday 02 February 2011 17:37:02 Russell King - ARM Linux wrote:
>> We used to use inline assembly at one point, but that got chucked out.
>> The problem is that using asm() for this causes GCC to generate horrid
>> code.
>> 
>> 1. there's no way to tell GCC that the inline assembly is a load
>>    instruction and therefore it needs to schedule the following
>>    instructions appropriately.
>> 
>> 2. GCC will needlessly reload pointers from structures and other such
>>    behaviour because it can't be told clearly what the inline assembly
>>    is doing, so the inline asm needs to have a "memory" clobber.
>> 
>> 3. It seems to misses out using the pre-index addressing, prefering to
>>    create add/sub instructions prior to each inline assembly load/store.
>> 
>> 4. There are no (documented) constraints in GCC to allow you to represent
>>    the offset format for the half-word instructions.
>> 
>> Overall, it means greater register pressure, more instructions, larger
>> functions, greater instruction cache pressure, etc.
>
> Another solution would be to declare the readl function extern and define
> it out of line, but I assume that this would be at least as bad as an
> inline assembly for all the points you brought up, right?
>
> Would it be possible to add the proper constraints for defining readl
> in an efficient way to a future version of gcc? That wouldn't help us
> in the near future, but we could at some points use those in a number
> of places.

I think it would be quite difficult to implement item 1 above in a way
that was actually usable.  It would require some way to describe the
scheduling requirements of an asm.  But the details of scheduling are
backend specific.  Internally there are define_insn_reservation
structures which have names, but the names are processor specific which
is not what you want in source code (by processor specific I mean
specific to particular CPUs within a family).  There are define_cpu_unit
structures which also have names, but are again processor specific.
What you want here is some non-processor-specific way to describe the
characteristics of an instruction.  gcc does not have that today.

Even if somebody implemented all that, most inline asms are not a single
instructions and thus would find it difficult to take advantage of it.
I don't see this as paying off in the long run.

A more likely payoff would be to develop builtin functions for whatever
functionality is required that can not expressed in source code.

Item 2 above can be done.  It is possible to describe precisely which
areas of memory are clobbered.

Item 3 above seems impossible to me.  There is no way to combine
compiler generated instructions with user written inline asm such that
pre-index addressing can be used.  Perhaps I misunderstand.

Item 4 can be implemented; please consider opening a feature request in
bugzilla.

Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists