IA64 alignment rule is no diff from x86, as far as I know.
Sun

On Sat, May 5, 2012 at 3:36 PM, Gang Yu <yugang...@gmail.com> wrote:

> Sun,
>
> Changes in cgemit.cxx, i.e,
>
> @@ -9995,21 +9995,7 @@ EMT_End_File( void )
>          Em_End_Section (em_scn[i].scninfo);
>        }
>        if (Assembly) {
> -       UINT32 tmp, power;
> -       power = 0;
> -       for (tmp = STB_align(sym); tmp > 1; tmp >>= 1) power++;
> -#if defined(BUILD_OS_DARWIN)
> -       emit_section_directive(sym);
> -#else
> -       fprintf (Asm_File, "\t%s %s\n", AS_SECTION, ST_name(sym));
> -#endif /* defined(BUILD_OS_DARWIN) */
> -#ifndef TARG_IA64
> -#if defined(TARG_X8664) && ! defined(BUILD_OS_DARWIN)
> -       fprintf (Asm_File, "\t%s\t%d\n", AS_ALIGN, 1 << power );
> -#else
> -       fprintf (Asm_File, "\t%s\t%d\n", AS_ALIGN, power);
> -#endif
> -#else
> +#ifdef TARG_IA64
>         ASM_DIR_ALIGN(power, sym);
>  #endif
>        }
>
> is to eliminate the section align at the end of assembly file, since we
> decide to make the section align at the section emit init phase. But we
> keep the IA64 target's special handling, in general it is different to
> x86_64. At the same time, I may find some problems in the above deletion
> since later changes are in x86_64 specific files, so this changes the
> behavior for non x86 targets which I am not verified. I will check it more,
> thank you, Sun.
>
> following changes:
>
> -BOOL
> -CGEMIT_Align_Section_Once (const char *scn_name)
> -{
> -  return strcmp(scn_name, ".literal") && strcmp(scn_name, ".text");
> -}
> -
>  void
>  CGEMIT_Prn_File_Dir_In_Asm(
> USRCPOS usrcpos,
>                          const char *pathname,
> @@ -312,8 +306,12 @@ CGEMIT_Prn_Scn_In_Asm (FILE       *asm_file,
>       place/align all data items relative to the start of the
>       section. But some we always align. */
> -  if (!CGEMIT_Align_Section_Once(
>  scn_name))
> -    fprintf (asm_file, "\t%s\t%d\n", AS_ALIGN, scn_align);
> +#ifdef BUILD_OS_DARWIN
> +  fprintf (asm_file, "\t%s\t%d\n", AS_ALIGN, scn_align);
> +#else
> +  fprintf (asm_file, "\t%s\t%d\n", AS_ALIGN, 1 << scn_align);
> +#endif
> +
>
> are to emit the align directive at the section init phase, now we emit the
> section align for all sections, not just ".text" and ".literal", so
> function CGEMIT_Align_Section_Once can be removed, at the same time, we
> handle differently for BUILD_OS_DARWIN since the asm syntax different.
>
> Regards
> Gang
>
>
>
> On Fri, May 4, 2012 at 10:15 PM, Sun Chan <sun.c...@gmail.com> wrote:
>
>> can you explain a bit why you change it the way you are now? The diff is
>> something very minor, thus, should not have caused that many lines of
>> change.
>>
>>  On Fri, May 4, 2012 at 1:58 PM, Gang Yu <yugang...@gmail.com> wrote:
>>
>>>  Hi,
>>>
>>>    Could a gatekeeper please help review the fix for bug974(
>>> https://bugs.open64.net/show_bug.cgi?id=974)?
>>>
>>> This is a code-size issue, however, we can't ignore the slightly
>>> behavior difference compared to GCC, that will break the link for opencc's
>>> build kernel 3.0.x.
>>>
>>> A cut-down case below:
>>>
>>> int a[17]={1,2,3};
>>> int main(int argc, char* argv[]){
>>>   a[3] = 5;
>>>   return a[3];
>>> }
>>> opencc secalign.c -o opencc.out
>>> yug@jupiter:~/work/codesize/secalign> objdump -h opencc.out | grep
>>> \\.data
>>>  24 .data         00000070  0000000000601010  0000000000601010
>>> 00001010  2**4
>>> gcc secalign.c -o gcc.out
>>> yug@jupiter:~/work/codesize/secalign> objdump -h gcc.out | grep \\.data
>>>  25 .data         00000064  0000000000601020  0000000000601020
>>> 00001020  2**5
>>> we get different section size for .data, gcc with(0x64) vs opencc with
>>> (0x70).
>>>
>>> Examine the assemble file, we get gcc's dump:
>>>         .data
>>>         .align 32
>>>         .type   a, @object
>>>         .size   a, 68
>>> a:
>>>         .long   1
>>>         .long   2
>>>         .long   3
>>>         .zero   56
>>> while opencc's dump:
>>>         .section .data
>>>         .org 0x0
>>>         .align  0
>>> .globl  a
>>>         .type   a, @object
>>>         .size   a, 68
>>> a:      # 0x0
>>>         # offset 0
>>>         .4byte  1
>>>         # offset 4
>>>         .4byte  2
>>>         # offset 8
>>>         .4byte  3
>>>         .skip 56
>>>         # end of initialization for a
>>>         .section .text
>>>         .align  4
>>>         .section .data
>>>         .align  16
>>>
>>> we see that gcc's section directive is strictly follwed by the align
>>> directive, it means the assembler switch to the new section and aligned
>>> firstly to make the section
>>> symbol aligned.
>>> while opencc's does not do section align at the beginning, instead, it
>>> aligns sections at the end of assembler,
>>> this makes the section aligned ready for the next file compiling.
>>> Both implementations seem reasonable, but, for the code-size
>>> consideration and also GCC compatibility,
>>> we can switch to align the section when we firstly initialize the
>>> section.
>>>
>>> Suggested patch:
>>> osprey/be/cg/cgemit.cxx    -- 12a31e9..727bdc1 100644
>>> --- a/osprey/be/cg/cgemit.cxx
>>> +++ b/osprey/be/cg/cgemit.cxx
>>> @@ -9995,21 +9995,7 @@ EMT_End_File( void )
>>>          Em_End_Section (em_scn[i].scninfo);
>>>        }
>>>        if (Assembly) {
>>> -       UINT32 tmp, power;
>>> -       power = 0;
>>> -       for (tmp = STB_align(sym); tmp > 1; tmp >>= 1) power++;
>>> -#if defined(BUILD_OS_DARWIN)
>>> -       emit_section_directive(sym);
>>> -#else
>>> -       fprintf (Asm_File, "\t%s %s\n", AS_SECTION, ST_name(sym));
>>> -#endif /* defined(BUILD_OS_DARWIN) */
>>> -#ifndef TARG_IA64
>>> -#if defined(TARG_X8664) && ! defined(BUILD_OS_DARWIN)
>>> -       fprintf (Asm_File, "\t%s\t%d\n", AS_ALIGN, 1 << power );
>>> -#else
>>> -       fprintf (Asm_File, "\t%s\t%d\n", AS_ALIGN, power);
>>> -#endif
>>> -#else
>>> +#ifdef TARG_IA64
>>>         ASM_DIR_ALIGN(power, sym);
>>>  #endif
>>>        }
>>> osprey/be/cg/x8664/cgemit_targ.cxx    -- fe6b994..f0eeda2 100644
>>> --- a/osprey/be/cg/x8664/cgemit_targ.cxx
>>> +++ b/osprey/be/cg/x8664/cgemit_targ.cxx
>>> @@ -134,12 +134,6 @@ CGEMIT_Targ_Text_Finalize (ST *pu)
>>>  }
>>>
>>> -BOOL
>>> -CGEMIT_Align_Section_Once (const char *scn_name)
>>> -{
>>> -  return strcmp(scn_name, ".literal") && strcmp(scn_name, ".text");
>>> -}
>>> -
>>>  void
>>>  CGEMIT_Prn_File_Dir_In_Asm(USRCPOS usrcpos,
>>>                          const char *pathname,
>>> @@ -312,8 +306,12 @@ CGEMIT_Prn_Scn_In_Asm (FILE       *asm_file,
>>>       place/align all data items relative to the start of the
>>>       section. But some we always align. */
>>> -  if (!CGEMIT_Align_Section_Once(scn_name))
>>> -    fprintf (asm_file, "\t%s\t%d\n", AS_ALIGN, scn_align);
>>> +#ifdef BUILD_OS_DARWIN
>>> +  fprintf (asm_file, "\t%s\t%d\n", AS_ALIGN, scn_align);
>>> +#else
>>> +  fprintf (asm_file, "\t%s\t%d\n", AS_ALIGN, 1 << scn_align);
>>> +#endif
>>> +
>>>  #if defined(BUILD_OS_DARWIN)
>>>    /* Darwin "as" doesn't automatically define the section name to be a
>>> symbol
>>>
>>>
>>> Regards
>>> Gang
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Open64-devel mailing list
>>> Open64-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>
>>>
>>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to