(un)aligned accesses on x86 platform.

(un)aligned accesses on x86 platform.

[Paweł Sikora]

hi,

during development a cross platform appliacation on x86 workstation
i've enabled an alignemnt checking [1] to catch possible erroneous
code before it appears on client's sparc/arm cpu with sigbus ;)

it works pretty fine and catches alignment violations but Jakub Jelinek
had told me (on glibc bugzilla) that gcc on x86 can still dereference
an unaligned pointer (except for vector insns).
i suppose it means that gcc can emit e.g. movl for access a short int
(or maybe others scenarios) in some cases and violates cpu alignment rules.

so, is it possible to instruct gcc-x86 to always use suitable loads/stores
like on sparc/arm?

[1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)

BR,
Pawel.

Re: (un)aligned accesses on x86 platform.

[Andrew Pinski]

You define STRICT_ALIGNED to be 1 in i386.h or provide an option to  
turn that on/off like the rs6000 target does.

Thanks,
Andrew Pinski

Sent from my iPhone

On Mar 8, 2010, at 7:37 AM, Paweł Sikora <pluto@agmk.net> wrote:

> hi,
>
> during development a cross platform appliacation on x86 workstation
> i've enabled an alignemnt checking [1] to catch possible erroneous
> code before it appears on client's sparc/arm cpu with sigbus ;)
>
> it works pretty fine and catches alignment violations but Jakub  
> Jelinek
> had told me (on glibc bugzilla) that gcc on x86 can still dereference
> an unaligned pointer (except for vector insns).
> i suppose it means that gcc can emit e.g. movl for access a short int
> (or maybe others scenarios) in some cases and violates cpu alignment  
> rules.
>
> so, is it possible to instruct gcc-x86 to always use suitable loads/ 
> stores
> like on sparc/arm?
>
> [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)
>
> BR,
> Pawel.

Re: (un)aligned accesses on x86 platform.

[Richard Guenther]

2010/3/8 Paweł Sikora <pluto@agmk.net>:
> hi,
>
> during development a cross platform appliacation on x86 workstation
> i've enabled an alignemnt checking [1] to catch possible erroneous
> code before it appears on client's sparc/arm cpu with sigbus ;)
>
> it works pretty fine and catches alignment violations but Jakub Jelinek
> had told me (on glibc bugzilla) that gcc on x86 can still dereference
> an unaligned pointer (except for vector insns).
> i suppose it means that gcc can emit e.g. movl for access a short int
> (or maybe others scenarios) in some cases and violates cpu alignment rules.
>
> so, is it possible to instruct gcc-x86 to always use suitable loads/stores
> like on sparc/arm?

Only by re-building it and setting STRICT_ALIGNMENT.

Richard.

> [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)
>
> BR,
> Pawel.
>

Re: (un)aligned accesses on x86 platform.

[Paweł Sikora]

On Monday 08 March 2010 16:46:10 Richard Guenther wrote:
> 2010/3/8 Paweł Sikora <pluto@agmk.net>:
> > hi,
> > 
> > during development a cross platform appliacation on x86 workstation
> > i've enabled an alignemnt checking [1] to catch possible erroneous
> > code before it appears on client's sparc/arm cpu with sigbus ;)
> > 
> > it works pretty fine and catches alignment violations but Jakub Jelinek
> > had told me (on glibc bugzilla) that gcc on x86 can still dereference
> > an unaligned pointer (except for vector insns).
> > i suppose it means that gcc can emit e.g. movl for access a short int
> > (or maybe others scenarios) in some cases and violates cpu alignment
> > rules.
> > 
> > so, is it possible to instruct gcc-x86 to always use suitable
> > loads/stores like on sparc/arm?
> 
> Only by re-building it and setting STRICT_ALIGNMENT.

oops, we have a problem with 4.4.x bootstrap ;)
http://imgbin.org/index.php?page=image&id=1356

Re: (un)aligned accesses on x86 platform.

[H.J. Lu]

2010/3/8 Paweł Sikora <pluto@agmk.net>:
> hi,
>
> during development a cross platform appliacation on x86 workstation
> i've enabled an alignemnt checking [1] to catch possible erroneous
> code before it appears on client's sparc/arm cpu with sigbus ;)
>
> it works pretty fine and catches alignment violations but Jakub Jelinek
> had told me (on glibc bugzilla) that gcc on x86 can still dereference
> an unaligned pointer (except for vector insns).
> i suppose it means that gcc can emit e.g. movl for access a short int
> (or maybe others scenarios) in some cases and violates cpu alignment rules.
>
> so, is it possible to instruct gcc-x86 to always use suitable loads/stores
> like on sparc/arm?
>
> [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)
>

I am interested in an -mstrict-alignment option for x86.

-- 
H.J.

Re: (un)aligned accesses on x86 platform.

[Tristan Gingold]

On Mar 16, 2010, at 3:50 PM, H.J. Lu wrote:

> 2010/3/8 Paweł Sikora <pluto@agmk.net>:
>> hi,
>> 
>> during development a cross platform appliacation on x86 workstation
>> i've enabled an alignemnt checking [1] to catch possible erroneous
>> code before it appears on client's sparc/arm cpu with sigbus ;)
>> 
>> it works pretty fine and catches alignment violations but Jakub Jelinek
>> had told me (on glibc bugzilla) that gcc on x86 can still dereference
>> an unaligned pointer (except for vector insns).
>> i suppose it means that gcc can emit e.g. movl for access a short int
>> (or maybe others scenarios) in some cases and violates cpu alignment rules.
>> 
>> so, is it possible to instruct gcc-x86 to always use suitable loads/stores
>> like on sparc/arm?
>> 
>> [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)
>> 
> 
> I am interested in an -mstrict-alignment option for x86.

Not sure it will be useful.  The libc still does unaligned accesses IIRC.

Re: (un)aligned accesses on x86 platform.

[Alexey Salmin]

On Tue, Mar 16, 2010 at 9:05 PM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Mar 16, 2010, at 3:50 PM, H.J. Lu wrote:
>
>> 2010/3/8 Paweł Sikora <pluto@agmk.net>:
>>> hi,
>>>
>>> during development a cross platform appliacation on x86 workstation
>>> i've enabled an alignemnt checking [1] to catch possible erroneous
>>> code before it appears on client's sparc/arm cpu with sigbus ;)
>>>
>>> it works pretty fine and catches alignment violations but Jakub Jelinek
>>> had told me (on glibc bugzilla) that gcc on x86 can still dereference
>>> an unaligned pointer (except for vector insns).
>>> i suppose it means that gcc can emit e.g. movl for access a short int
>>> (or maybe others scenarios) in some cases and violates cpu alignment rules.
>>>
>>> so, is it possible to instruct gcc-x86 to always use suitable loads/stores
>>> like on sparc/arm?
>>>
>>> [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)
>>>
>>
>> I am interested in an -mstrict-alignment option for x86.
>
> Not sure it will be useful.  The libc still does unaligned accesses IIRC.
>
>

Wow. What for?

Alexey

Re: (un)aligned accesses on x86 platform.

[Tristan Gingold]

On Mar 16, 2010, at 4:37 PM, Alexey Salmin wrote:
>>> I am interested in an -mstrict-alignment option for x86.
>> 
>> Not sure it will be useful.  The libc still does unaligned accesses IIRC.
>> 
> 
> Wow. What for?

Well, simply because it is not compiled with strict alignment.  There might also be some optimization in
memory operation that does unaligned accesses.

Re: (un)aligned accesses on x86 platform.

[Alexey Salmin]

On Tue, Mar 16, 2010 at 9:48 PM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Mar 16, 2010, at 4:37 PM, Alexey Salmin wrote:
>>>> I am interested in an -mstrict-alignment option for x86.
>>>
>>> Not sure it will be useful.  The libc still does unaligned accesses IIRC.
>>>
>>
>> Wow. What for?
>
> Well, simply because it is not compiled with strict alignment.  There might also be some optimization in
> memory operation that does unaligned accesses.

I always thought that unaligned access is much slower than aligned
one. You mean code-size optimizations?

Alexey

Re: (un)aligned accesses on x86 platform.

[Piotr Wyderski]

Alexey Salmin wrote:

> I always thought that unaligned access is much slower than aligned one.

It is not *MUCH* slower, just slower (unless you cross cache line
boundary). Unaligned accesses are very useful for improving
performance of, among other things, certain hash functions (e.g. Paul
Hsieh's one).

Best regards,
Piotr Wyderski

Re: (un)aligned accesses on x86 platform.

[Jakub Jelinek]

On Tue, Mar 16, 2010 at 10:04:04PM +0600, Alexey Salmin wrote:
> >> Wow. What for?
> >
> > Well, simply because it is not compiled with strict alignment.  There might also be some optimization in
> > memory operation that does unaligned accesses.
> 
> I always thought that unaligned access is much slower than aligned
> one. You mean code-size optimizations?

It is, but if you need to choose between doing say an unaligned 32-bit
read access and reading it in 4 8-bit reads and assembling those together,
on many targets that do allow unaligned accesses the former is much faster.
Especially if in most cases the read is actually aligned and only in rare
cases it is unaligned...

	Jakub

Re: (un)aligned accesses on x86 platform.

[Mikael Pettersson]

On Tue, 16 Mar 2010 06:50:30 -0800,  H.J. Lu <hjl.tools@gmail.com> wrote:
> 2010/3/8 Pawe=C5=82 Sikora <pluto@agmk.net>:
> > hi,
> >
> > during development a cross platform appliacation on x86 workstation
> > i've enabled an alignemnt checking [1] to catch possible erroneous
> > code before it appears on client's sparc/arm cpu with sigbus ;)
> >
> > it works pretty fine and catches alignment violations but Jakub Jelinek
> > had told me (on glibc bugzilla) that gcc on x86 can still dereference
> > an unaligned pointer (except for vector insns).
> > i suppose it means that gcc can emit e.g. movl for access a short int
> > (or maybe others scenarios) in some cases and violates cpu alignment rule=
> s.
> >
> > so, is it possible to instruct gcc-x86 to always use suitable loads/stores
> > like on sparc/arm?
> >
> > [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing)
> >
> 
> I am interested in an -mstrict-alignment option for x86.

Me too. One use I have in mind is in emulators for ISAs that require
alignment checks. Setting the AC bit would allow the emulator to replace
explicit alignment checks with the x86 host's alignment checks, which
could speed up emulation and reduce code volume (for JITs).

However, this relies on gcc and glibc to not generate too many misaligned
accesses. The glibc bit can be worked around (use a replacement libc or
offload libc accesses to a sibling thread that runs with AC=0), but gcc
does need to be instructed to not generate code with misaligned accesses.

Another use is in implementations of dynamically-typed languages like Lisp.
You can choose a tagging scheme so that CAR and CDR become simple loads with
appropriate offsets. If the tagged pointer happens to not be a CONS, you'll
get an alignment exception.

/Mikael