public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Yaro Pollak <yarop@altair-semi.com>
To: David Edelsohn <dje@watson.ibm.com>, gcc-help@gcc.gnu.org
Subject: Re: Unaligned access to packed structs on ppc405
Date: Mon, 06 Feb 2006 10:18:00 -0000	[thread overview]
Message-ID: <43E72258.708@altair-semi.com> (raw)
In-Reply-To: <200602052102.k15L2BD28758@makai.watson.ibm.com>

What seems odd to me is that packed structures accesses are inherently 
less efficient than non-packed structures.
In my example, the 3 lbz instructions instead of one lwz require 3 
memory accesses instead of 1, that is a penalty of 2 extra memory access 
over the slow bus, and in addition to that there is extra penalty when 
the bit field overlaps byte boundary (as in my example), where GCC must 
generate extra code to "or" those bytes, which, BTW, in my opinion 
contradicts what you wrote earlier:

David Edelsohn wrote:
" The lbz has to do with the size and the packed alignment. With the 
packed structure, GCC chooses the smallest memory access that covers the 
bitfield. Once GCC has chosen bytes, it cannot merge the loads together. 
If the structure were not declared packed, GCC would use wider loads 
with masking, and then determine that the loads refer to the same object."

In my case it shouldn't have chosen byte because it doesn't cover the bitfield that spans over byte boundary. I don't know whether what GCC does is "Right", and I guess if it was implemented in 4.1 somebody decided that it was "Right", but, if the code generated is 3 times the instruction count, and 3 times the memory accesses, for no apparent reason, then I can't see any reason why anyone would want this behavior. I mean the code produced in 4.0.1 for the same structure accessed not through a pointer is just fine, why break it like that? Something just doesn't seem right, I'm sorry.

I think I can summarize it by saying that if it's less efficient then 
there is no justification for it.

Yaro



David Edelsohn wrote:
>>>>>> John Yates writes:
>>>>>>             
>
> John> Do I read this correctly?  Are you truly saying that two structs
> John> with identical layout will trigger different code sequences just
> John> because one was declared packed?
>
> 	Yes.  Why is that strange?  attribute packed assigns the smallest
> possible alignment so that the compiler composes the layout of the
> structure or bitfield in the more compact form possible.  Even if the
> layout produced is the same, the smaller alignment is carried around with
> the fields and causes the compiler to use more conservative access
> operations. 
>
> David
>
>
>   

  reply	other threads:[~2006-02-06 10:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-05 18:35 John Yates
2006-02-05 21:02 ` David Edelsohn
2006-02-06 10:18   ` Yaro Pollak [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-02-01 12:03 [Re: Unaligned access to packed structs on ppc405] Yaro Pollak
2006-02-04  4:25 ` Unaligned access to packed structs on ppc405 David Edelsohn
2006-01-30 16:18 Matthew Jones
2006-01-30 16:26 ` Yaro Pollak
2006-01-29 17:16 David Edelsohn
2006-01-30 12:03 ` Yaro Pollak
2006-02-02 16:13   ` David Edelsohn
2006-01-29 10:00 Yaro Pollak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43E72258.708@altair-semi.com \
    --to=yarop@altair-semi.com \
    --cc=dje@watson.ibm.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).