[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-11-27 22:57 -------
I think this was fixed by:
2006-01-10  Jan Beulich  <jbeulich@novell.com>

        * config/i386/i386.c (ix86_data_alignment): Don't force alignment to
        256 bits when optimize_size.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2006-11-27 23:03 -------
This was also fixed.
s2:
        .long   .LC0
        .data
        .align 4
        .type   s3, @object
        .size   s3, 49
s3:
        .string "111111111111111111111111111111111111111111111111"


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug tree-optimization/22158] New: char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

static char *s0 = "000000000000000000000000000000000000000000000000";
static char s1[] = "111111111111111111111111111111111111111111111111";
static char *s2 = "000000000000000000000000000000000000000000000000";
static char s3[] = "111111111111111111111111111111111111111111111111";

void f(char*);
void g() {
    f(s0);
    f(s1);
    f(s2);
    f(s3);
}

s1 and s2 are aligned on 32 bytes even with -Os, while s2 and s4 are not.
See http://gcc.gnu.org/ml/gcc/2002-01/msg01068.html,
http://gcc.gnu.org/ml/gcc/2002-01/msg01068/i386.c.PATCH

-- 
           Summary: char global_var[] = "larger than 32 bytes"; uses silly
                    amounts of alignment even with -Os
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vda at port dot imtp dot ilyichevsk dot odessa dot ua
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-23 12:02 -------
Why do you think this is a bug?
Note the alignment change was done to support MMX/SSE:
<http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00860.html>.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

------- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua  2005-06-23 12:56 -------
In majority of cases char msg[] = "A message" is used for text strings.
These are _bytes_, they need no alignment whatsoever, let alone 32 byte one.

I'm perfectly fine if other people want to do it, but I don't, so I use -Os.
I want to suppress this behavior for -Os.

Is it a bug or not is a matter of definition 'what is a bug' really...

BTW what is that another mysterious piece of code aligning something else to 32
bytes?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

------- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua  2005-06-23 13:03 -------
Oh, I did look at http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00860.html,
I see 128 and 256 bit alignment added, but I don't immediately see where it is
applied to byte arrays (strings) - patch is not so small, where should I look?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-23 13:12 -------
(In reply to comment #7)
> Oh, I did look at http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00860.html,
> I see 128 and 256 bit alignment added, but I don't immediately see where it is
> applied to byte arrays (strings) - patch is not so small, where should I look?

actually that did not add it, it was there before that patch, just moved it to the function.
The comment above DATA_ALIGNMENT in i386.h should explain why it was this is done:
   One use of this macro is to increase alignment of medium-size
   data to make it all fit in fewer cache lines.  Another is to 
   cause character arrays to be word-aligned so that `strcpy' calls
   that copy constants to character arrays can be done inline.  */

Though this should be moved to i386.c so this question no longer is there.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[vda at port dot imtp dot ilyichevsk dot odessa dot ua]

------- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua  2005-06-24 06:34 -------
>One use of this macro is to increase alignment of medium-size
>data to make it all fit in fewer cache lines.

1) This potentially makes single string fit into fewer cachelines,
but it noticeably increases the sum of all strings!
2) If cacheline is >32bytes, this optimization can even make things worse:

Unaligned string fits into 64 byte (say, Athlon64) cacheline:
[..some_string.]
^0      ^32     ^64

Same string spills over to second cacheline after alignment:
[.......some_st][ring.......]
^0      ^32     ^64

>Another is to 
>cause character arrays to be word-aligned so that `strcpy' calls
>that copy constants to character arrays can be done inline.

I do not fully understand. Is it about non-static local
char arrays initialized by string?

void f() {
    char s[] = "Long str";
}

How alignment affects this code? x86 CPUs can do unaligned loads/stores
just fine, thus 'inlinability' of implicit strcpy does not depend on alignment.
Also such local arrays are not very typical, so why optimize for this case?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[pluto at agmk dot net]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pluto at agmk dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158

[Bug target/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|i386-pc-linux-gnu           |
   GCC host triplet|i386-pc-linux-gnu           |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158