alignment

alignment

[Andrew Morton]

On x86, both gcc 2.7.2.3 and "2.96 19991116" are inserting `.align 4'
ops after `jmp' instructions and also prior to `__asm__ __volatile__'.

This causes a ~5% code size increase in the one Linux kernel file I
looked at.

Why does the compiler do this, and what would be the downside of turning
it off?

Thanks.

Re: alignment

[Tim Prince]

Did you do any performance studies?  Did you enable the use of .p2align,
and did that change the situation?  On the code I have worked with, I
saw no reason for using __volatile__ other than to hide bugs, and that
may make a difference.

Tim Prince
----- Original Message -----
From: "Andrew Morton" <andrewm@uow.edu.au>
To: <gcc@gcc.gnu.org>
Sent: Saturday, July 15, 2000 5:51 AM
Subject: alignment


> On x86, both gcc 2.7.2.3 and "2.96 19991116" are inserting `.align 4'
> ops after `jmp' instructions and also prior to `__asm__ __volatile__'.
>
> This causes a ~5% code size increase in the one Linux kernel file I
> looked at.
>
> Why does the compiler do this, and what would be the downside of
turning
> it off?
>
> Thanks.

Re: alignment

[Linus Torvalds]

In article < 006401bfee63$0d4ff4a0$0100000a@TIMYX18EWDT6RQ >,
Tim Prince <tprince@computer.org> wrote:
>Did you do any performance studies?  Did you enable the use of .p2align,
>and did that change the situation?  On the code I have worked with, I
>saw no reason for using __volatile__ other than to hide bugs, and that
>may make a difference.

The gcc manual explicitly states:

	Note that if there are only unused output operands, you will
	then also need to specify @code{volatile} for the @code{asm}
	construct, as described below. 

	...

	If the side-effects of your instruction are not purely external,
	but will affect variables in your program in ways other than
	reading the inputs and clobbering the specified registers or
	memory, you should write the @code{volatile} keyword to prevent
	future versions of GNU CC from moving the instruction around
	within a core region. 

	...

For example, a common thing to do is to encode the "inb" instruction on
x86, which gcc has absolutely no way of getting at any other way than
through the use of inline asm. 

The natural encoding for "inb" would be:

	static inline unsigned char inb(unsigned short port)
	{
		unsigned char byte;
		asm("inb":"=a" (byte):"Nd" (port));
		return byte;
	}

would you not agree?

However, the above is WRONG. It is wrong because:

 - it can get re-ordered

 - it can get deleted if the value is not actually used

both of which are very very wrong, as the "inb" instruction obviously
has tons of side effects that basically cannot be described to the
compiler. 

Pray tell me how you'd fix that without the use of "volatile"?

[ Yes, you _can_ fix it. You can lie. You can say that the instruction
  changes memory, and use a "memory" clobber. That should make gcc
  unable to re-order it or remove it, because we're saying that it
  changes memory in ways that gcc doesn't know about. Is that really the
  preferred syntax? And if so, what's the point in having a __volatile__
  at all? Makes no sense to me: the __volatile__ thing at least is
  conceptually understandable, a "memory" clobber would just be an
  obvious workaround for a lack in the compiler ]

In short, your statement that "volatile" is mainly to be used to hide
bugs is nonsense, and it's obviously equally non-sensical for gcc to
insert a ".align" directive in front of the asm.

If the user is using inline assembly and really wants to align the code,
he can damn well do so by hand.  The compiler doing it for him is
obviously an extremely silly thing to do that buys absolutely nothing.

			Linus

Re: alignment

[Richard Henderson]

On Sat, Jul 15, 2000 at 10:51:43PM +1000, Andrew Morton wrote:
> On x86, both gcc 2.7.2.3 and "2.96 19991116" are inserting `.align 4'
> ops after `jmp' instructions and also prior to `__asm__ __volatile__'.

Eh?  Alignments before an asm?  I don't believe you.  The
alignment is surely associated with a nearby label.

> Why does the compiler do this, and what would be the downside of
> turning it off?

Because modern x86 instruction decoding is sensitive to alignment.
The only downside to turning it off is potential code slowdown.
See -malign-loops= and -malign-jumps= and -malign-functions=.

We should have also tied these to -Os, but I see that we havn't.
I'll fix that shortly.


r~

Re: alignment

[Geoff Keating]

Richard Henderson <rth@cygnus.com> writes:

> See -malign-loops= and -malign-jumps= and -malign-functions=.
> 
> We should have also tied these to -Os, but I see that we havn't.
> I'll fix that shortly.

The preferred fix is to convert the backend to the -falign-* options
instead, which do the right thing with -Os.  See for instance the
sparc port.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: Alignment

[Branko Čibej]

DI Christian Schmidleitner wrote:

> have to transfer a great software package (3 millions line of code, 500
>structures) from SCO-UNIX, SCO-XENIX and AIX to Linux. I have to share the
>files between the old systems and the new one. All structures are compiled
>with 2 Byte alignment.
>In Xenix: cc
>In SCO-UNIX: cc -Xm -a ods30 -Z p2
>In AIX: cc -qaligned=twobyte.
>Now I search the correct options for the gcc.
>I hope you can help me.
>
http://gcc.gnu.org/onlinedocs/

>DI Christian Schmidleitner
>Oberhaiderstr. 59
>A-4600 Wels
>Austria/Europe
>

Alignment

[DI Christian Schmidleitner]

 have to transfer a great software package (3 millions line of code, 500
structures) from SCO-UNIX, SCO-XENIX and AIX to Linux. I have to share the
files between the old systems and the new one. All structures are compiled
with 2 Byte alignment.
In Xenix: cc
In SCO-UNIX: cc -Xm -a ods30 -Z p2
In AIX: cc -qaligned=twobyte.
Now I search the correct options for the gcc.
I hope you can help me.

DI Christian Schmidleitner
Oberhaiderstr. 59
A-4600 Wels
Austria/Europe

Re: alignment

[Linus Torvalds]

On Sat, 15 Jul 2000, Tim Prince wrote:
>
>		 If the kernel code has been checked thoroughly to
> see that __volatile__ is required everywhere it is used, then my comment
> is superfluous for that application.

I don't know that we have checked that there are no superfluous
"volatiles". For all I know there might certainly be volatiles that could
be dropped from the kernel.

I do find it strange that gcc would emit a .align directing before a
volatile asm, and I assume that is because there is some "virtual
branch-target" there to ensure volatility or similar. I don't see the
reported behaviour on the gcc version I'm using (2.91.66), so this
behaviour is new (or maybe it's more subtle than "before every volatile",
or maybe I mis-understood the report).

[ Side comment: most of the asm's inside the kernel tend to be volatile
  for one reason or another: they tend to be synchronization points.
  Things like spinlocks, "disable interrupts" etc. I don't think the
  kernel is really all that consistent about "volatile": a number of them
  use memory clobbers instead of "volatile" to avoid getting moved
  around too much. ]

		Linus

Re: alignment

[Tim Prince]

I certainly didn't mean to make a blanket statement that __volatile__ is
unnecessary, and I appreciate the clarification as to when it is
necessary.  The situations where I believe that __volatile__ would
better be eliminated, provided that sufficient checking is done,  have
no unused output operands.  One of the hidden bugs which I have in mind
is the possibility of float stack overflow, which sometimes is avoided
(but not reliably so) by use of __volatile__ rather than working out the
required clobbers. That situation, of course, doesn't apply often, if at
all, in the kernel. If the kernel code has been checked thoroughly to
see that __volatile__ is required everywhere it is used, then my comment
is superfluous for that application.  However, I took the OP as a
general comment on the efficiency of gcc which was not restricted to the
kernel application, and I did not notice all the cross posts, or I would
have deleted some on my reply.

Tim Prince

"Linus Torvalds" <torvalds@transmeta.com> wrote in message
news: 200007151735.KAA03129@penguin.transmeta.com ...
> In article < 006401bfee63$0d4ff4a0$0100000a@TIMYX18EWDT6RQ >,
> Tim Prince <tprince@computer.org> wrote:
> >Did you do any performance studies?  Did you enable the use of
.p2align,
> >and did that change the situation?  On the code I have worked with, I
> >saw no reason for using __volatile__ other than to hide bugs, and
that
> >may make a difference.
>
> The gcc manual explicitly states:
>
> Note that if there are only unused output operands, you will
> then also need to specify @code{volatile} for the @code{asm}
> construct, as described below.
>
> ...
>
> If the side-effects of your instruction are not purely external,
> but will affect variables in your program in ways other than
> reading the inputs and clobbering the specified registers or
> memory, you should write the @code{volatile} keyword to prevent
> future versions of GNU CC from moving the instruction around
> within a core region.
>
> ...
>
> For example, a common thing to do is to encode the "inb" instruction
on
> x86, which gcc has absolutely no way of getting at any other way than
> through the use of inline asm.
>
> The natural encoding for "inb" would be:
>
> static inline unsigned char inb(unsigned short port)
> {
> unsigned char byte;
> asm("inb":"=a" (byte):"Nd" (port));
> return byte;
> }
>
> would you not agree?
>
> However, the above is WRONG. It is wrong because:
>
>  - it can get re-ordered
>
>  - it can get deleted if the value is not actually used
>
> both of which are very very wrong, as the "inb" instruction obviously
> has tons of side effects that basically cannot be described to the
> compiler.
>
> Pray tell me how you'd fix that without the use of "volatile"?
>
> [ Yes, you _can_ fix it. You can lie. You can say that the instruction
>   changes memory, and use a "memory" clobber. That should make gcc
>   unable to re-order it or remove it, because we're saying that it
>   changes memory in ways that gcc doesn't know about. Is that really
the
>   preferred syntax? And if so, what's the point in having a
__volatile__
>   at all? Makes no sense to me: the __volatile__ thing at least is
>   conceptually understandable, a "memory" clobber would just be an
>   obvious workaround for a lack in the compiler ]
>
> In short, your statement that "volatile" is mainly to be used to hide
> bugs is nonsense, and it's obviously equally non-sensical for gcc to
> insert a ".align" directive in front of the asm.
>
> If the user is using inline assembly and really wants to align the
code,
> he can damn well do so by hand.  The compiler doing it for him is
> obviously an extremely silly thing to do that buys absolutely nothing.
>
> Linus