[PING v2][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
Ping 2, and pasted my observation about this ICE, and may someone can help?
The main cause for the ICE is in the function symtab_get_node:
gcc_checking_assert (TREE_CODE (decl) == FUNCTION_DECL
|| (TREE_CODE (decl) == VAR_DECL
&& (TREE_STATIC (decl) || DECL_EXTERNAL (decl)
|| in_lto_p)));
It's a check for the tree attribute for VAR_DECL, but as the register type
variable is neither static nor
external(not sure if this is correct), the compiler will raise ICE here, but in
function
make_decl_rtl(gcc/varasm.c:1357), there's one line comment:
globalize_reg (decl, reg_number + --nregs);
}
/* As a register variable, it has no section. */
return;
}
And for the correct register type declaration like: register int *a asm("r1"),
the program will just directly
return(gcc/varasm.c:1358), and won't sink into the symbol ref generation part.
So symtab_get_node won't be
called.
Currently invalid register type declaration will always sink into the symbol
ref generation part of function
make_decl_rtl, which will also lead to wrong rtx generation.
register int *a asm("r1")=>(reg:SI 1 r1 [orig:0 a] [0])
register int *a asm("unknown register")=>(symbol_ref:SI ("unknown register")
[flag 0x80])
Also the reason that x86 wont't have sunch an ICE is in the code:
if (use_object_blocks_p () && use_blocks_for_decl_p (decl))
x = create_block_symbol (name, get_block_for_decl (decl), -1);
function use_object_blocks_p will always return false on target doesn't support
section anchor, so function
get_block_for_decl which will call symtab_get_node will never be called.
This patch just move the else condition in make_decl_rtl to make all register
type declaration to get the
same rtx, it this a reasonable fix?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Tony Wang
> Sent: Tuesday, August 05, 2014 9:35 AM
> To: gcc-patches@gcc.gnu.org
> Cc: 'Richard Biener'; 'Jakub Jelinek'
> Subject: [PING][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
>
> Ping, any comment and suggestion on this bug fix?
>
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Tony Wang
> > Sent: Tuesday, July 29, 2014 10:31 AM
> > To: gcc-patches@gcc.gnu.org; 'Richard Biener'; 'Jakub Jelinek'
> > Subject: [Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
> >
> > Hi there,
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330.
> > There will be an ICE in gcc trunk for targets support section anchor
> > optimization when compiling this case(like arm and mips). This looks like
> an
>
> The target should be aarch64, arm, powerpc, alpha
>
> > old bug which is exposed by recent patch.
> >
> > In make_decl_rtl, when you declare register type incorrectly like
> "register int
> > *a asm("unknown register");", the compiler will raise an error messge but
> > doesn't return directly. It will continue to run into the rtx generation
> code for
> > general variable declaration and generate a wrong rtx:(symbol_ref:SI...).
> So I
> > just remove the else condition which used to be the rtx generation part
> for
> > correctly declared register type, and let all the register type
> declaration(no
> > matter it declared correct or not) go through it and generate the same
> type
> > of rtx:(reg:SI...).
> >
> > gcc/ChangeLog:
> >
> > 2014-07-29 Tony Wang tony.w...@arm.com
> >
> > * gcc/varasm.c (make_decl_rtl): Remove the else condition
> > for properly declared static register variables.
> >
> > diff --git a/gcc/varasm.c b/gcc/varasm.c index 819ec26..a6fae0c 100644
> > --- a/gcc/varasm.c
> > +++ b/gcc/varasm.c
> > @@ -1333,45 +1333,42 @@ make_decl_rtl (tree decl)
> >error ("register specified for %q+D isn%'t suitable for
> data type",
> > decl);
> >/* Now handle properly declared static register variables. */
> > - else
> > - {
> > -int nregs;
> > + int nregs;
> >
> > -if (DECL_INITIAL (decl) != 0 && TREE_STATIC (decl))
> > - {
> > -DECL_INITIAL (decl) = 0;
> > -error ("global register variable has initial value");
> > - }
> > -if (
[PING v3][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
Ping? Still on the trunk now.
> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Tuesday, August 12, 2014 9:32 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PING v2][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
>
> Ping 2, and pasted my observation about this ICE, and may someone can help?
>
> The main cause for the ICE is in the function symtab_get_node:
>
> gcc_checking_assert (TREE_CODE (decl) == FUNCTION_DECL
> || (TREE_CODE (decl) == VAR_DECL
> && (TREE_STATIC (decl) || DECL_EXTERNAL (decl)
> || in_lto_p)));
>
> It's a check for the tree attribute for VAR_DECL, but as the register type
> variable is neither static nor
external(not
> sure if this is correct), the compiler will raise ICE here, but in function
make_decl_rtl(gcc/varasm.c:1357), there's
> one line comment:
>
> globalize_reg (decl, reg_number + --nregs);
> }
>
> /* As a register variable, it has no section. */
> return;
> }
>
> And for the correct register type declaration like: register int *a
> asm("r1"), the program will just
directly
> return(gcc/varasm.c:1358), and won't sink into the symbol ref generation
> part. So symtab_get_node won't be
> called.
>
> Currently invalid register type declaration will always sink into the symbol
> ref generation part of function
> make_decl_rtl, which will also lead to wrong rtx generation.
> register int *a asm("r1")=>(reg:SI 1 r1 [orig:0 a] [0])
> register int *a asm("unknown register")=>(symbol_ref:SI ("unknown register")
> [flag 0x80])
>
> Also the reason that x86 wont't have sunch an ICE is in the code:
>
> if (use_object_blocks_p () && use_blocks_for_decl_p (decl))
> x = create_block_symbol (name, get_block_for_decl (decl), -1);
>
> function use_object_blocks_p will always return false on target doesn't
> support section anchor, so function
> get_block_for_decl which will call symtab_get_node will never be called.
>
> This patch just move the else condition in make_decl_rtl to make all
> register type declaration to get the
same rtx,
> it this a reasonable fix?
>
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
> > On Behalf Of Tony Wang
> > Sent: Tuesday, August 05, 2014 9:35 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: 'Richard Biener'; 'Jakub Jelinek'
> > Subject: [PING][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
> >
> > Ping, any comment and suggestion on this bug fix?
> >
> > > -Original Message-
> > > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > > ow...@gcc.gnu.org] On Behalf Of Tony Wang
> > > Sent: Tuesday, July 29, 2014 10:31 AM
> > > To: gcc-patches@gcc.gnu.org; 'Richard Biener'; 'Jakub Jelinek'
> > > Subject: [Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
> > >
> > > Hi there,
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330.
> > > There will be an ICE in gcc trunk for targets support section anchor
> > > optimization when compiling this case(like arm and mips). This looks like
> > an
> >
> > The target should be aarch64, arm, powerpc, alpha
> >
> > > old bug which is exposed by recent patch.
> > >
> > > In make_decl_rtl, when you declare register type incorrectly like
> > "register int
> > > *a asm("unknown register");", the compiler will raise an error messge but
> > > doesn't return directly. It will continue to run into the rtx generation
> > code for
> > > general variable declaration and generate a wrong rtx:(symbol_ref:SI...).
> > So I
> > > just remove the else condition which used to be the rtx generation part
> > for
> > > correctly declared register type, and let all the register type
> > declaration(no
> > > matter it declared correct or not) go through it and generate the same
> > type
> > > of rtx:(reg:SI...).
> > >
> > > gcc/ChangeLog:
> > >
> > > 2014-07-29 Tony Wang tony.w...@arm.com
> > >
> > > * gcc/varasm.c (make_decl_rtl): Remove the else condition
> > > for properly declared static register variables.
> > >
> > > diff --git a/gcc/varasm.c b/gcc/varasm.c index 819ec26..a6fae0c 100644
> > > --- a/gcc/varasm.c
> > > +++ b/gcc/varasm.c
&g
[PATCH, g++, testsuite] Skip thread_local6.C on target using wrapper
Hi there,
It's a very simple test case modification to fix the test case failure on ARM
bare metal target.
thread_local6.C is a test case to test the behavior of the deconstruct of a
thread local variable, and it just
use _exit(0) to override the return 1(calling exit(1)). However, such a
behavior can't be detected on embedded
target with dejagnu wrapper mechanism, because the wrapper will only output the
return value in exit() instead
of _exit(). There're some similar test cases(g++.dg/init/ref15.C) already
avoided to test on the target using
wrapper, so this patch just follow their pattern to avoid the test case on
target using wrapper.
gcc/gcc/testsuite/ChangeLog:
2014-08-20 Tony Wang
* g++.dg/tls/thread_local6.C: Skip this test case when
target uses dejagnu wrapper.
diff --git a/gcc/testsuite/g++.dg/tls/thread_local6.C
b/gcc/testsuite/g++.dg/tls/thread_local6.C
index
378cf3d58c7bcbebb224137b353301f75b420d5a..6cf820e0e9a181e403aa2c0ebaa822ab7b6f7aab
100644
--- a/gcc/testsuite/g++.dg/tls/thread_local6.C
+++ b/gcc/testsuite/g++.dg/tls/thread_local6.C
@@ -1,6 +1,6 @@
// Test for cleanups in the main thread without -pthread.
-// { dg-do run { target c++11 } }
+// { dg-do run { target { c++11 && unwrapped } } }
// { dg-add-options tls }
// { dg-require-effective-target tls_runtime }
[PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Hi there, In libgcc the file ieee754-sf.S and ieee754-df.S have some function pairs which will be bundled into one .o file and sharing the same .text section. For example, the fmul and fdiv, the libgcc makefile will build them into one .o file and archived into libgcc.a. So when user only call single float point multiply functions, the fdiv function will also be linked, and as fmul and fdiv share the same .text section, linker option --gc-sections or -flot can't remove the dead code. So this optimization just separates the function pair(fmul/fdiv and dmul/ddiv) into different sections, following the naming pattern of -ffunction-sections(.text.__functionname), through which the unused sections of fdiv/ddiv can be eliminated through option --gcc-sections when users only use fmul/dmul.The solution is to add a conditional statement in the macro FUNC_START, which will conditional change the section of a function from .text to .text.__\name. when compiling with the L_arm_muldivsf3 or L_arm_muldivdf3 macro. GCC regression test has been done on QEMU for Cortex-M3. No new regressions when turn on this patch. The code reduction for thumb2 on cortex-m3 is: 1. When user only use single float point multiply: fmul+fdiv => fmul will have a code size reduction of 318 bytes. 2. When user only use double float point multiply: dmul+ddiv => dmul will have a code size reduction of 474 bytes. Ok for trunk? BR, Tony Step 1: Provide another option: sp-scetion to control whether to split the section of a function pair into two part. gcc/libgcc/ChangeLog: 2014-08-21 Tony Wang * config/arm/lib1funcs.S (FUNC_START): Add conditional section redefine for macro L_arm_muldivsf3 and L_arm_muldivdf3 (SYM_END, ARM_SYM_START): Add macros used to expose function Symbols diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S index b617137..0f87111 100644 --- a/libgcc/config/arm/lib1funcs.S +++ b/libgcc/config/arm/lib1funcs.S @@ -418,8 +418,12 @@ SYM (\name): #define THUMB_SYNTAX #endif -.macro FUNC_START name +.macro FUNC_START name sp_section= + .ifc \sp_section, function_section + .section.text.__\name,"ax",%progbits + .else .text + .endif .globl SYM (__\name) TYPE (__\name) .align 0 @@ -429,14 +433,24 @@ SYM (\name): SYM (__\name): .endm +.macro ARM_SYM_START name + TYPE (\name) + .align 0 +SYM (\name): +.endm + +.macro SYM_END name + SIZE (\name) +.endm + /* Special function that will always be coded in ARM assembly, even if in Thumb-only compilation. */ #if defined(__thumb2__) /* For Thumb-2 we build everything in thumb mode. */ -.macro ARM_FUNC_START name - FUNC_START \name +.macro ARM_FUNC_START name sp_section= + FUNC_START \name \sp_section .syntax unified .endm #define EQUIV .thumb_set @@ -467,8 +481,12 @@ _L__\name: #ifdef __ARM_ARCH_6M__ #define EQUIV .thumb_set #else -.macro ARM_FUNC_START name +.macro ARM_FUNC_START name sp_section= + .ifc \sp_section, function_section + .section.text.__\name,"ax",%progbits + .else .text + .endif .globl SYM (__\name) TYPE (__\name) .align 0 libgcc_mul_div_code_size_reduction_1.diff Description: Binary data
[PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Step 2: Mark all the symbols around the fragment boundaries as function symbols, so as to generate veneer when the two section is too far away from each other. Also, I have both manually and using some test cases to verify that IP and PSR are not alive at such point. gcc/libgcc/ChangeLog: 2014-8-21 Tony Wang * config/arm/ieee754-sf.S: Expose symbols around fragment boundaries as function symbols. * config/arm/ieee754-df.S: Same with above BR, Tony libgcc_mul_div_code_size_reduction_2.diff Description: Binary data
[PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Step 3: Test cases to verify the code size reduction.
gcc/gcc/testsuite/ChangeLog:
2014-08-21 Tony Wang
* gcc.target/arm/size-optimization-ieee-1.c: New test case
* gcc.target/arm/size-optimization-ieee-2.c: New test case
* lib/gcc-dg.exp: Add new function scan-symbol-common, scan-symbol-yes,
scan-symbol-no to scan a user defined symbol in final elf file
BR,
Tony
diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
new file mode 100644
index 000..46e9cdf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
@@ -0,0 +1,30 @@
+/* { dg-do link { target { arm_thumb2_ok } } } */
+/* { dg-options "-Wl,--gc-sections" } */
+int
+foo ()
+{
+ volatile float a;
+ volatile float b;
+ volatile float c = a * b;
+ return 0;
+}
+
+int
+bar ()
+{
+ volatile double a;
+ volatile double b;
+ volatile double c = a * b;
+ return 0;
+}
+
+int
+main ()
+{
+ foo ();
+ bar ();
+ return 0;
+}
+/* { dg-final { scan-symbol-no "__aeabi_fdiv" } } */
+/* { dg-final { scan-symbol-no "__aeabi_ddiv" } } */
+
diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
new file mode 100644
index 000..5007d62
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
@@ -0,0 +1,30 @@
+/* { dg-do link { target { arm_thumb2_ok } } } */
+/* { dg-options "-Wl,--gc-sections" } */
+int
+foo ()
+{
+ volatile float a;
+ volatile float b;
+ volatile float c = a / b;
+ return 0;
+}
+
+int
+bar ()
+{
+ volatile double a;
+ volatile double b;
+ volatile double c = a / b;
+ return 0;
+}
+
+int
+main ()
+{
+ foo ();
+ bar ();
+ return 0;
+}
+/* { dg-final { scan-symbol-yes "__aeabi_fmul" } } */
+/* { dg-final { scan-symbol-yes "__aeabi_dmul" } } */
+
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 3390caa..0d52e95 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -880,5 +880,57 @@ proc gdb-exists { args } {
return 0;
}
+# Scan the OUTPUT_FILE for a symbol. Return 1 if it present, or
+# return 0 if it doesn't present
+
+proc scan-symbol-common { args } {
+global nm
+global base_dir
+
+set testcase [testname-for-summary]
+set output_file "[file rootname [file tail $testcase]].exe"
+
+# Find nm like we find g++ in g++.exp.
+if ![info exists nm] {
+set nm [findfile $base_dir/../../../binutils/nm \
+$base_dir/../../../binutils/nm \
+[findfile $base_dir/../../nm $base_dir/../../nm \
+ [findfile $base_dir/nm $base_dir/nm \
+ [transform nm
+verbose -log "nm is $nm"
+}
+
+if { $output_file == "" } {
+fail "scan-symbol-not $args: dump file does not exist"
+return
+}
+
+set fd [open "| $nm $output_file" r]
+set text [read $fd]
+close $fd
+
+if [regexp -- [lindex $args 0] $text] {
+return 1
+} else {
+return 0
+}
+}
+
+proc scan-symbol-yes { args } {
+if { [scan-symbol-common $args] == 1 } {
+ pass "scan-symbol-yes $args exists"
+} else {
+ fail "scan-symbol-yes $args does not exist"
+}
+}
+
+proc scan-symbol-no { args } {
+if { [scan-symbol-common $args] != 1 } {
+pass "scan-symbol-no $args does not exist"
+} else {
+fail "scan-symbol-no $args exists"
+}
+}
+
set additional_prunes ""
set dg_runtest_extra_prunes ""
libgcc_mul_div_code_size_reduction_3.diff
Description: Binary data
[PATCH, libstdc++, testsuite]Skip 62154.cc for target don't support the atomic builtins
It's a very simple patch. Some target don't support atomic builtins, so all
related test cases should be
disabled. In folder libstdc++-v3/testsuite/18_support/nested_exception, all
other test cases have already been
disabled for target don't have atomic builtins.
gcc/libstdc++-v3/ChangeLog:
2014-08-21 Tony Wang
* testsuite/18_support/nested_exception/62154.cc: Disable
this test case when target don't have atomic buildins.
diff --git a/libstdc++-v3/testsuite/18_support/nested_exception/62154.cc
b/libstdc++-v3/testsuite/18_support/nested_exception/62154.cc
index 9c6725f..da6ed4c 100644
--- a/libstdc++-v3/testsuite/18_support/nested_exception/62154.cc
+++ b/libstdc++-v3/testsuite/18_support/nested_exception/62154.cc
@@ -1,4 +1,5 @@
// { dg-options "-std=gnu++11" }
+// { dg-require-atomic-builtins "" }
// Copyright (C) 2014 Free Software Foundation, Inc.
//
RE: [PATCH, g++, testsuite] Skip thread_local6.C on target using wrapper
Hi Mike > Hum, another solution might be to wrap _exit as well. The patch is so simple > and short, I'll approve the posted > patch; it is a nice step forward. I'll let you contemplate if you want to > try a wrap on _exit. > Thanks for your reply, and I also thought of your suggestion to wrap the _exit. The fact is that dejagnu does the wrapper to both exit() and _exit(), but it give a higher priority to the exit(), which means if you both call exit() and _exit(), it will only output the return value in exit(). Someone told me that you shouldn't explicitly call _exit() inside an exit(), and that's why the dejagnu skip the second _exit() output. However, I'm not sure about this, as there're quite a few c++ test cases are doing the same thing. > Could you please add /* wrapping doesn't reflect _exit value */ if you add > this version. This can go on line 3. If > _exit isn't used, this is the clue we can then run the test case more often, > and if someone wants to copy the use > of _exit or fix wrapping, this is a handy clue for this. Ok, I will commit with this version. BR, Tony
[Patch ARM] Fix PR target/56846
Hi all,
The bug is reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846, and
it’s about the problem that
when exception handler is involved in the function, then _Unwind_Backtrace
function will run into deadloop on
arm target.
Cmd line: arm-none-eabi-g++ -mthumb -mcpu=cortex-m3 -O0 -g -std=c++11
-specs=rdimon.specs main.c -o main.exe
#include
#include
_Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg)
{
void *ip = (void *)_Unwind_GetIP(context);
printf("Address: %p\n", ip);
return _URC_NO_REASON;
}
void bar()
{
puts("This is in bar");
_Unwind_Backtrace((_Unwind_Trace_Fn)&trace_func, 0);
}
void foo()
{
try
{
bar();
}
catch (...)
{
puts("Exception");
}
}
The potential of such a bug is discussed long time ago in mail:
https://gcc.gnu.org/ml/gcc/2007-08/msg00235.html. Basically, as the ARM EHABI
does not define how to implement
the Unwind_Backtrace, Andrew give control to the personality routine to unwind
the stack, and use the unwind
state combination of “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND” to represent
that the caller is asking the
personality routine to only unwind the stack for it.
However, the pr in the libstdc++-v3 doesn’t handle such a unwind state pattern
correctly. When the backtrace
function passes such a pattern to it, it will still return _URC_HANDLER_FOUND
to the caller in some cases.
It’s because the pr will think that the _Unwind_Backtrace is raising a none
type exception to it, so if the
exception handler in current stack frame can catch anything(like catch(…)), the
pr will return
_URC_HANDLER_FOUND to the caller and ask for next step. But definitely, the
unwind backtrace function don’t
know what to do when pr return an exception handler to it.
So this patch just evaluate such a unwind state pattern at the beginning of the
personality routine in
libstdc++-v3, if we meet with “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND”,
then we directly call macro
CONTINUE_UNWINDING to unwind the stack and return.
Is this a reasonable fix?
gcc/libstdc++-v3/ChangeLog:
2014-8-25 Tony Wang
PR target/56846
* libsupc++/eh_personality.cc: Return with CONTINUE_UNWINDING
when meet with the unwind state pattern:
_US_VIRTUAL_UNWIND_FRAME |
_US_FORCE_UNWIND
diff --git a/libstdc++-v3/libsupc++/eh_personality.cc
b/libstdc++-v3/libsupc++/eh_personality.cc
index f315a83..c2b30e9 100644
--- a/libstdc++-v3/libsupc++/eh_personality.cc
+++ b/libstdc++-v3/libsupc++/eh_personality.cc
@@ -378,6 +378,11 @@ PERSONALITY_FUNCTION (int version,
switch (state & _US_ACTION_MASK)
{
case _US_VIRTUAL_UNWIND_FRAME:
+ // If the unwind state pattern is _US_VIRTUAL_UNWIND_FRAME |
+ // _US_FORCE_UNWIND, we don't need to search for any handler
+ // as it is not a real exception. Just unwind the stack.
+ if (state & _US_FORCE_UNWIND)
+ CONTINUE_UNWINDING;
actions = _UA_SEARCH_PHASE;
break;
RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping? > -Original Message- > From: Tony Wang [mailto:tony.w...@arm.com] > Sent: Thursday, August 21, 2014 2:15 PM > To: 'gcc-patches@gcc.gnu.org' > Subject: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and > dmul/ddiv function in libgcc > > Hi there, > > In libgcc the file ieee754-sf.S and ieee754-df.S have some function pairs > which will be bundled into one .o file and > sharing the same .text section. For example, the fmul and fdiv, the libgcc > makefile will build them into one .o file > and archived into libgcc.a. So when user only call single float point > multiply functions, the fdiv function will also be > linked, and as fmul and fdiv share the same .text section, linker option > --gc-sections or -flot can't remove the > dead code. > > So this optimization just separates the function pair(fmul/fdiv and > dmul/ddiv) into different sections, following > the naming pattern of -ffunction-sections(.text.__functionname), through > which the unused sections of > fdiv/ddiv can be eliminated through option --gcc-sections when users only use > fmul/dmul.The solution is to add > a conditional statement in the macro FUNC_START, which will conditional > change the section of a function > from .text to .text.__\name. when compiling with the L_arm_muldivsf3 or > L_arm_muldivdf3 macro. > > GCC regression test has been done on QEMU for Cortex-M3. No new regressions > when turn on this patch. > > The code reduction for thumb2 on cortex-m3 is: > 1. When user only use single float point multiply: > fmul+fdiv => fmul will have a code size reduction of 318 bytes. > > 2. When user only use double float point multiply: > dmul+ddiv => dmul will have a code size reduction of 474 bytes. > > Ok for trunk? > > BR, > Tony > > Step 1: Provide another option: sp-scetion to control whether to split the > section of a function pair into two part. > > gcc/libgcc/ChangeLog: > 2014-08-21 Tony Wang > > * config/arm/lib1funcs.S (FUNC_START): Add conditional section > redefine for macro L_arm_muldivsf3 and L_arm_muldivdf3 > (SYM_END, ARM_SYM_START): Add macros used to expose function > Symbols > > diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S > index b617137..0f87111 100644 > --- a/libgcc/config/arm/lib1funcs.S > +++ b/libgcc/config/arm/lib1funcs.S > @@ -418,8 +418,12 @@ SYM (\name): > #define THUMB_SYNTAX > #endif > > -.macro FUNC_START name > +.macro FUNC_START name sp_section= > + .ifc \sp_section, function_section > + .section.text.__\name,"ax",%progbits > + .else > .text > + .endif > .globl SYM (__\name) > TYPE (__\name) > .align 0 > @@ -429,14 +433,24 @@ SYM (\name): > SYM (__\name): > .endm > > +.macro ARM_SYM_START name > + TYPE (\name) > + .align 0 > +SYM (\name): > +.endm > + > +.macro SYM_END name > + SIZE (\name) > +.endm > + > /* Special function that will always be coded in ARM assembly, even if > in Thumb-only compilation. */ > > #if defined(__thumb2__) > > /* For Thumb-2 we build everything in thumb mode. */ > -.macro ARM_FUNC_START name > - FUNC_START \name > +.macro ARM_FUNC_START name sp_section= > + FUNC_START \name \sp_section > .syntax unified > .endm > #define EQUIV .thumb_set > @@ -467,8 +481,12 @@ _L__\name: > #ifdef __ARM_ARCH_6M__ > #define EQUIV .thumb_set > #else > -.macro ARM_FUNC_START name > +.macro ARM_FUNC_START name sp_section= > + .ifc \sp_section, function_section > + .section.text.__\name,"ax",%progbits > + .else > .text > + .endif > .globl SYM (__\name) > TYPE (__\name) > .align 0
RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping? > -Original Message- > From: Tony Wang [mailto:tony.w...@arm.com] > Sent: Thursday, August 21, 2014 2:15 PM > To: 'gcc-patches@gcc.gnu.org' > Subject: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and > dmul/ddiv function in libgcc > > Step 2: Mark all the symbols around the fragment boundaries as function > symbols, so as to generate veneer > when the two section is too far away from each other. Also, I have both > manually and using some test cases to > verify that IP and PSR are not alive at such point. > > gcc/libgcc/ChangeLog: > 2014-8-21 Tony Wang > > * config/arm/ieee754-sf.S: Expose symbols around fragment boundaries > as function symbols. > * config/arm/ieee754-df.S: Same with above > > BR, > Tony
RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping?
> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Thursday, August 21, 2014 2:15 PM
> To: 'gcc-patches@gcc.gnu.org'
> Subject: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and
> dmul/ddiv function in libgcc
>
> Step 3: Test cases to verify the code size reduction.
>
> gcc/gcc/testsuite/ChangeLog:
> 2014-08-21 Tony Wang
>
> * gcc.target/arm/size-optimization-ieee-1.c: New test case
> * gcc.target/arm/size-optimization-ieee-2.c: New test case
> * lib/gcc-dg.exp: Add new function scan-symbol-common,
> scan-symbol-yes,
> scan-symbol-no to scan a user defined symbol in final elf file
>
> BR,
> Tony
>
> diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
> b/gcc/testsuite/gcc.target/arm/size-
> optimization-ieee-1.c
> new file mode 100644
> index 000..46e9cdf
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
> @@ -0,0 +1,30 @@
> +/* { dg-do link { target { arm_thumb2_ok } } } */
> +/* { dg-options "-Wl,--gc-sections" } */
> +int
> +foo ()
> +{
> + volatile float a;
> + volatile float b;
> + volatile float c = a * b;
> + return 0;
> +}
> +
> +int
> +bar ()
> +{
> + volatile double a;
> + volatile double b;
> + volatile double c = a * b;
> + return 0;
> +}
> +
> +int
> +main ()
> +{
> + foo ();
> + bar ();
> + return 0;
> +}
> +/* { dg-final { scan-symbol-no "__aeabi_fdiv" } } */
> +/* { dg-final { scan-symbol-no "__aeabi_ddiv" } } */
> +
> diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
> b/gcc/testsuite/gcc.target/arm/size-
> optimization-ieee-2.c
> new file mode 100644
> index 000..5007d62
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
> @@ -0,0 +1,30 @@
> +/* { dg-do link { target { arm_thumb2_ok } } } */
> +/* { dg-options "-Wl,--gc-sections" } */
> +int
> +foo ()
> +{
> + volatile float a;
> + volatile float b;
> + volatile float c = a / b;
> + return 0;
> +}
> +
> +int
> +bar ()
> +{
> + volatile double a;
> + volatile double b;
> + volatile double c = a / b;
> + return 0;
> +}
> +
> +int
> +main ()
> +{
> + foo ();
> + bar ();
> + return 0;
> +}
> +/* { dg-final { scan-symbol-yes "__aeabi_fmul" } } */
> +/* { dg-final { scan-symbol-yes "__aeabi_dmul" } } */
> +
> diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> index 3390caa..0d52e95 100644
> --- a/gcc/testsuite/lib/gcc-dg.exp
> +++ b/gcc/testsuite/lib/gcc-dg.exp
> @@ -880,5 +880,57 @@ proc gdb-exists { args } {
> return 0;
> }
>
> +# Scan the OUTPUT_FILE for a symbol. Return 1 if it present, or
> +# return 0 if it doesn't present
> +
> +proc scan-symbol-common { args } {
> +global nm
> +global base_dir
> +
> +set testcase [testname-for-summary]
> +set output_file "[file rootname [file tail $testcase]].exe"
> +
> +# Find nm like we find g++ in g++.exp.
> +if ![info exists nm] {
> +set nm [findfile $base_dir/../../../binutils/nm \
> +$base_dir/../../../binutils/nm \
> +[findfile $base_dir/../../nm $base_dir/../../nm \
> + [findfile $base_dir/nm $base_dir/nm \
> + [transform nm
> +verbose -log "nm is $nm"
> +}
> +
> +if { $output_file == "" } {
> +fail "scan-symbol-not $args: dump file does not exist"
> +return
> +}
> +
> +set fd [open "| $nm $output_file" r]
> +set text [read $fd]
> +close $fd
> +
> +if [regexp -- [lindex $args 0] $text] {
> +return 1
> +} else {
> +return 0
> +}
> +}
> +
> +proc scan-symbol-yes { args } {
> +if { [scan-symbol-common $args] == 1 } {
> + pass "scan-symbol-yes $args exists"
> +} else {
> + fail "scan-symbol-yes $args does not exist"
> +}
> +}
> +
> +proc scan-symbol-no { args } {
> +if { [scan-symbol-common $args] != 1 } {
> +pass "scan-symbol-no $args does not exist"
> +} else {
> +fail "scan-symbol-no $args exists"
> +}
> +}
> +
> set additional_prunes ""
> set dg_runtest_extra_prunes ""
RE: [Patch ARM] Fix PR target/56846
Ping?
> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Monday, August 25, 2014 6:33 PM
> To: 'gcc-patches@gcc.gnu.org'; 'd...@debian.org';
> 'aph-...@littlepinkcloud.com'; Richard Earnshaw; Ramana
> Radhakrishnan
> Subject: [Patch ARM] Fix PR target/56846
>
> Hi all,
>
> The bug is reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846,
> and it’s about the problem that
> when exception handler is involved in the function, then _Unwind_Backtrace
> function will run into deadloop
on
> arm target.
>
> Cmd line: arm-none-eabi-g++ -mthumb -mcpu=cortex-m3 -O0 -g -std=c++11
> -specs=rdimon.specs main.c -o
> main.exe
> #include
> #include
> _Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg)
> {
> void *ip = (void *)_Unwind_GetIP(context);
> printf("Address: %p\n", ip);
> return _URC_NO_REASON;
> }
> void bar()
> {
> puts("This is in bar");
> _Unwind_Backtrace((_Unwind_Trace_Fn)&trace_func, 0);
> }
> void foo()
> {
> try
> {
> bar();
> }
> catch (...)
> {
> puts("Exception");
> }
> }
>
> The potential of such a bug is discussed long time ago in mail:
> https://gcc.gnu.org/ml/gcc/2007-
> 08/msg00235.html. Basically, as the ARM EHABI does not define how to
> implement the Unwind_Backtrace,
> Andrew give control to the personality routine to unwind the stack, and use
> the unwind state combination of
> “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND” to represent that the caller is
> asking the personality
> routine to only unwind the stack for it.
>
> However, the pr in the libstdc++-v3 doesn’t handle such a unwind state
> pattern correctly. When the backtrace
> function passes such a pattern to it, it will still return _URC_HANDLER_FOUND
> to the caller in some cases.
It’s
> because the pr will think that the _Unwind_Backtrace is raising a none type
> exception to it, so if the
exception
> handler in current stack frame can catch anything(like catch(…)), the pr will
> return _URC_HANDLER_FOUND to
> the caller and ask for next step. But definitely, the unwind backtrace
> function don’t know what to do when
pr
> return an exception handler to it.
>
> So this patch just evaluate such a unwind state pattern at the beginning of
> the personality routine in
libstdc++-v3,
> if we meet with “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND”, then we
> directly call macro
> CONTINUE_UNWINDING to unwind the stack and return.
>
> Is this a reasonable fix?
>
> gcc/libstdc++-v3/ChangeLog:
> 2014-8-25 Tony Wang
>
> PR target/56846
> * libsupc++/eh_personality.cc: Return with CONTINUE_UNWINDING
> when meet with the unwind state pattern:
> _US_VIRTUAL_UNWIND_FRAME |
> _US_FORCE_UNWIND
>
> diff --git a/libstdc++-v3/libsupc++/eh_personality.cc
> b/libstdc++-v3/libsupc++/eh_personality.cc
> index f315a83..c2b30e9 100644
> --- a/libstdc++-v3/libsupc++/eh_personality.cc
> +++ b/libstdc++-v3/libsupc++/eh_personality.cc
> @@ -378,6 +378,11 @@ PERSONALITY_FUNCTION (int version,
> switch (state & _US_ACTION_MASK)
> {
> case _US_VIRTUAL_UNWIND_FRAME:
> + // If the unwind state pattern is _US_VIRTUAL_UNWIND_FRAME |
> + // _US_FORCE_UNWIND, we don't need to search for any handler
> + // as it is not a real exception. Just unwind the stack.
> + if (state & _US_FORCE_UNWIND)
> + CONTINUE_UNWINDING;
> actions = _UA_SEARCH_PHASE;
> break;
RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping 2? > -Original Message- > From: Tony Wang [mailto:tony.w...@arm.com] > Sent: Thursday, August 28, 2014 2:02 PM > To: 'gcc-patches@gcc.gnu.org' > Cc: Richard Earnshaw; Ramana Radhakrishnan > Subject: RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv > and dmul/ddiv function in libgcc > > Ping? > > > -Original Message- > > From: Tony Wang [mailto:tony.w...@arm.com] > > Sent: Thursday, August 21, 2014 2:15 PM > > To: 'gcc-patches@gcc.gnu.org' > > Subject: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and > > dmul/ddiv function in libgcc > > > > Hi there, > > > > In libgcc the file ieee754-sf.S and ieee754-df.S have some function pairs > > which will be bundled into one .o file > and > > sharing the same .text section. For example, the fmul and fdiv, the libgcc > > makefile will build them into one .o > file > > and archived into libgcc.a. So when user only call single float point > > multiply functions, the fdiv function will also > be > > linked, and as fmul and fdiv share the same .text section, linker option > > --gc-sections or -flot can't remove the > > dead code. > > > > So this optimization just separates the function pair(fmul/fdiv and > > dmul/ddiv) into different sections, following > > the naming pattern of -ffunction-sections(.text.__functionname), through > > which the unused sections of > > fdiv/ddiv can be eliminated through option --gcc-sections when users only > > use fmul/dmul.The solution is to > add > > a conditional statement in the macro FUNC_START, which will conditional > > change the section of a function > > from .text to .text.__\name. when compiling with the L_arm_muldivsf3 or > > L_arm_muldivdf3 macro. > > > > GCC regression test has been done on QEMU for Cortex-M3. No new regressions > > when turn on this patch. > > > > The code reduction for thumb2 on cortex-m3 is: > > 1. When user only use single float point multiply: > > fmul+fdiv => fmul will have a code size reduction of 318 bytes. > > > > 2. When user only use double float point multiply: > > dmul+ddiv => dmul will have a code size reduction of 474 bytes. > > > > Ok for trunk? > > > > BR, > > Tony > > > > Step 1: Provide another option: sp-scetion to control whether to split the > > section of a function pair into two > part. > > > > gcc/libgcc/ChangeLog: > > 2014-08-21 Tony Wang > > > > * config/arm/lib1funcs.S (FUNC_START): Add conditional section > > redefine for macro L_arm_muldivsf3 and L_arm_muldivdf3 > > (SYM_END, ARM_SYM_START): Add macros used to expose function > > Symbols > > > > diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S > > index b617137..0f87111 100644 > > --- a/libgcc/config/arm/lib1funcs.S > > +++ b/libgcc/config/arm/lib1funcs.S > > @@ -418,8 +418,12 @@ SYM (\name): > > #define THUMB_SYNTAX > > #endif > > > > -.macro FUNC_START name > > +.macro FUNC_START name sp_section= > > + .ifc \sp_section, function_section > > + .section.text.__\name,"ax",%progbits > > + .else > > .text > > + .endif > > .globl SYM (__\name) > > TYPE (__\name) > > .align 0 > > @@ -429,14 +433,24 @@ SYM (\name): > > SYM (__\name): > > .endm > > > > +.macro ARM_SYM_START name > > + TYPE (\name) > > + .align 0 > > +SYM (\name): > > +.endm > > + > > +.macro SYM_END name > > + SIZE (\name) > > +.endm > > + > > /* Special function that will always be coded in ARM assembly, even if > > in Thumb-only compilation. */ > > > > #if defined(__thumb2__) > > > > /* For Thumb-2 we build everything in thumb mode. */ > > -.macro ARM_FUNC_START name > > - FUNC_START \name > > +.macro ARM_FUNC_START name sp_section= > > + FUNC_START \name \sp_section > > .syntax unified > > .endm > > #define EQUIV .thumb_set > > @@ -467,8 +481,12 @@ _L__\name: > > #ifdef __ARM_ARCH_6M__ > > #define EQUIV .thumb_set > > #else > > -.macro ARM_FUNC_START name > > +.macro ARM_FUNC_START name sp_section= > > + .ifc \sp_section, function_section > > + .section.text.__\name,"ax",%progbits > > + .else > > .text > > + .endif > > .globl SYM (__\name) > > TYPE (__\name) > > .align 0
RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping 2? > -Original Message- > From: Tony Wang [mailto:tony.w...@arm.com] > Sent: Thursday, August 28, 2014 2:02 PM > To: 'gcc-patches@gcc.gnu.org' > Cc: Richard Earnshaw; Ramana Radhakrishnan > Subject: RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv > and dmul/ddiv function in libgcc > > Ping? > > > -Original Message- > > From: Tony Wang [mailto:tony.w...@arm.com] > > Sent: Thursday, August 21, 2014 2:15 PM > > To: 'gcc-patches@gcc.gnu.org' > > Subject: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and > > dmul/ddiv function in libgcc > > > > Step 2: Mark all the symbols around the fragment boundaries as function > > symbols, so as to generate veneer > > when the two section is too far away from each other. Also, I have both > > manually and using some test cases to > > verify that IP and PSR are not alive at such point. > > > > gcc/libgcc/ChangeLog: > > 2014-8-21 Tony Wang > > > > * config/arm/ieee754-sf.S: Expose symbols around fragment > > boundaries as function symbols. > > * config/arm/ieee754-df.S: Same with above > > > > BR, > > Tony libgcc_mul_div_code_size_reduction_2.diff Description: Binary data
RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping 2?
> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Thursday, August 28, 2014 2:02 PM
> To: 'gcc-patches@gcc.gnu.org'
> Cc: Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv
> and dmul/ddiv function in libgcc
>
> Ping?
>
> > -Original Message-
> > From: Tony Wang [mailto:tony.w...@arm.com]
> > Sent: Thursday, August 21, 2014 2:15 PM
> > To: 'gcc-patches@gcc.gnu.org'
> > Subject: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and
> > dmul/ddiv function in libgcc
> >
> > Step 3: Test cases to verify the code size reduction.
> >
> > gcc/gcc/testsuite/ChangeLog:
> > 2014-08-21 Tony Wang
> >
> > * gcc.target/arm/size-optimization-ieee-1.c: New test case
> > * gcc.target/arm/size-optimization-ieee-2.c: New test case
> > * lib/gcc-dg.exp: Add new function scan-symbol-common,
> > scan-symbol-yes,
> > scan-symbol-no to scan a user defined symbol in final elf file
> >
> > BR,
> > Tony
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
> > b/gcc/testsuite/gcc.target/arm/size-
> > optimization-ieee-1.c
> > new file mode 100644
> > index 000..46e9cdf
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
> > @@ -0,0 +1,30 @@
> > +/* { dg-do link { target { arm_thumb2_ok } } } */
> > +/* { dg-options "-Wl,--gc-sections" } */
> > +int
> > +foo ()
> > +{
> > + volatile float a;
> > + volatile float b;
> > + volatile float c = a * b;
> > + return 0;
> > +}
> > +
> > +int
> > +bar ()
> > +{
> > + volatile double a;
> > + volatile double b;
> > + volatile double c = a * b;
> > + return 0;
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + foo ();
> > + bar ();
> > + return 0;
> > +}
> > +/* { dg-final { scan-symbol-no "__aeabi_fdiv" } } */
> > +/* { dg-final { scan-symbol-no "__aeabi_ddiv" } } */
> > +
> > diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
> > b/gcc/testsuite/gcc.target/arm/size-
> > optimization-ieee-2.c
> > new file mode 100644
> > index 000..5007d62
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
> > @@ -0,0 +1,30 @@
> > +/* { dg-do link { target { arm_thumb2_ok } } } */
> > +/* { dg-options "-Wl,--gc-sections" } */
> > +int
> > +foo ()
> > +{
> > + volatile float a;
> > + volatile float b;
> > + volatile float c = a / b;
> > + return 0;
> > +}
> > +
> > +int
> > +bar ()
> > +{
> > + volatile double a;
> > + volatile double b;
> > + volatile double c = a / b;
> > + return 0;
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + foo ();
> > + bar ();
> > + return 0;
> > +}
> > +/* { dg-final { scan-symbol-yes "__aeabi_fmul" } } */
> > +/* { dg-final { scan-symbol-yes "__aeabi_dmul" } } */
> > +
> > diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> > index 3390caa..0d52e95 100644
> > --- a/gcc/testsuite/lib/gcc-dg.exp
> > +++ b/gcc/testsuite/lib/gcc-dg.exp
> > @@ -880,5 +880,57 @@ proc gdb-exists { args } {
> > return 0;
> > }
> >
> > +# Scan the OUTPUT_FILE for a symbol. Return 1 if it present, or
> > +# return 0 if it doesn't present
> > +
> > +proc scan-symbol-common { args } {
> > +global nm
> > +global base_dir
> > +
> > +set testcase [testname-for-summary]
> > +set output_file "[file rootname [file tail $testcase]].exe"
> > +
> > +# Find nm like we find g++ in g++.exp.
> > +if ![info exists nm] {
> > +set nm [findfile $base_dir/../../../binutils/nm \
> > +$base_dir/../../../binutils/nm \
> > +[findfile $base_dir/../../nm $base_dir/../../nm \
> > + [findfile $base_dir/nm $base_dir/nm \
> > + [transform nm
> > +verbose -log "nm is $nm"
> > +}
> > +
> > +if { $output_file == "" } {
> > +fail "scan-symbol-not $args: dump file does not exist"
> > +return
> > +}
> > +
> > +set fd [open "| $nm $output_file" r]
> > +set text [read $fd]
> > +close $fd
> > +
> > +if [regexp -- [lindex $args 0] $text] {
> > +return 1
> > +} else {
> > +return 0
> > +}
> > +}
> > +
> > +proc scan-symbol-yes { args } {
> > +if { [scan-symbol-common $args] == 1 } {
> > + pass "scan-symbol-yes $args exists"
> > +} else {
> > + fail "scan-symbol-yes $args does not exist"
> > +}
> > +}
> > +
> > +proc scan-symbol-no { args } {
> > +if { [scan-symbol-common $args] != 1 } {
> > +pass "scan-symbol-no $args does not exist"
> > +} else {
> > +fail "scan-symbol-no $args exists"
> > +}
> > +}
> > +
> > set additional_prunes ""
> > set dg_runtest_extra_prunes ""
[Patch, gcc, testsuite]Disable xordi3-opt.c/iordi3-opt.c on thumb1 target
Hi there,
This is a test case clean up patch, because orr/eor instruction for thumb1 has
only two variant:
ORRS ,
ORR ,
No is available for thumb1 encoding, so test case
xordi3-opt.c/iordi3-opt.c is invalid for thumb1
target. This patch just disabled them for thumb1 target.
Ok for the trunk?
gcc/gcc/testsuite/ChangeLog:
2014-09-04 Tony Wang
* gcc.target/arm/xordi3-opt.c: Disable this
test case for thumb1 target.
* gcc.target/arm/iordi3-opt.c: Ditto.
diff --git a/gcc/testsuite/gcc.target/arm/iordi3-opt.c
b/gcc/testsuite/gcc.target/arm/iordi3-opt.c
index b3f465b..63fbe0b 100644
--- a/gcc/testsuite/gcc.target/arm/iordi3-opt.c
+++ b/gcc/testsuite/gcc.target/arm/iordi3-opt.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { arm_arm_ok || arm_thumb2_ok} } } */
/* { dg-options "-O1" } */
unsigned long long or64 (unsigned long long input)
diff --git a/gcc/testsuite/gcc.target/arm/xordi3-opt.c
b/gcc/testsuite/gcc.target/arm/xordi3-opt.c
index 7e031c3..53b2bab 100644
--- a/gcc/testsuite/gcc.target/arm/xordi3-opt.c
+++ b/gcc/testsuite/gcc.target/arm/xordi3-opt.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { arm_arm_ok || arm_thumb2_ok} } } */
/* { dg-options "-O1" } */
unsigned long long xor64 (unsigned long long input)
[PATCH]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Hi there, In libgcc the file ieee754-sf.S and ieee754-df.S have some function pairs which will be bundled into one .o file and sharing the same .text section. For example, the fmul and fdiv, the libgcc makefile will build them into one .o file and archived into libgcc.a. So when user only call single float point multiply functions, the fdiv function will also be linked, and as fmul and fdiv share the same .text section, linker option --gc-sections or -flot can’t remove the dead code. So the optimization just separates the function pair(fmul/fdiv and dmul/ddiv) into different sections, following the naming pattern of –ffunction-sections(.text.__functionname), through which the unused sections of fdiv/ddiv can be eliminated through option --gcc-sections when users only use fmul/dmul.The solution is to add a conditional statement in the macro FUNC_START, which will conditional change the section of a function from .text to .text.__\name. when compiling with the L_arm_muldivsf3 or L_arm_muldivdf3 macro. There are 3 parts: mul, div and common. This patch puts mul and common together, so that user's multiply won't pull-in div, butuser's div will still pull-in mul. It is reasonable because size of mul is far smaller than size of div. ChangLog changes are: ***gcc/libgcc/ChangeLog*** 2014-05-28 Tony Wang * config/arm/lib1funcs.S (FUNC_START): Add conditional section redefine for macro L_arm_muldivsf3 and L_arm_muldivdf3 Bootstrapped on x86_64-linux-gnu and no regression found in the testsuite. Patch is in attachment. The code reduction for thumb2 on cortex-m3 is: 1. When user only use single float point multiply: fmul+fdiv => fmul will have a code size reduction of 318 bytes. 2. When user only use double float point multiply: dmul+ddiv => dmul will have a code size reduction of 474 bytes. BR, Tony diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S index b617137..0454bc8 100644 --- a/libgcc/config/arm/lib1funcs.S +++ b/libgcc/config/arm/lib1funcs.S @@ -419,7 +419,11 @@ SYM (\name): #endif .macro FUNC_START name +#if defined (L_arm_muldivsf3) || defined (L_arm_muldivdf3) + .section.text.__\name,"ax",%progbits +#else .text +#endif .globl SYM (__\name) TYPE (__\name) .align 0 @@ -468,7 +472,11 @@ _L__\name: #define EQUIV .thumb_set #else .macro ARM_FUNC_START name +#if defined (L_arm_muldivsf3) || defined (L_arm_muldivdf3) + .section.text.__\name,"ax",%progbits +#else .text +#endif .globl SYM (__\name) TYPE (__\name) .align 0
RE: [Patch ARM] Fix PR target/56846
> -Original Message-
> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
> Sent: Tuesday, September 09, 2014 4:33 PM
> To: Tony Wang
> Cc: gcc-patches; d...@debian.org; aph-...@littlepinkcloud.com; Richard
> Earnshaw; Ramana Radhakrishnan;
> libstd...@gcc.gnu.org
> Subject: Re: [Patch ARM] Fix PR target/56846
>
> On Mon, Aug 25, 2014 at 11:32 AM, Tony Wang wrote:
> > Hi all,
> >
> > The bug is reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846,
> > and it’s about the problem that
> > when exception handler is involved in the function, then _Unwind_Backtrace
> > function will run into deadloop
> on
> > arm target.
>
> You mean an infinite loop.
>
> >
> > Cmd line: arm-none-eabi-g++ -mthumb -mcpu=cortex-m3 -O0 -g -std=c++11
> > -specs=rdimon.specs main.c -o
> main.exe
> > #include
> > #include
> > _Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg)
> > {
> > void *ip = (void *)_Unwind_GetIP(context);
> > printf("Address: %p\n", ip);
> > return _URC_NO_REASON;
> > }
> > void bar()
> > {
> > puts("This is in bar");
> > _Unwind_Backtrace((_Unwind_Trace_Fn)&trace_func, 0);
> > }
> > void foo()
> > {
> > try
> > {
> > bar();
> > }
> > catch (...)
> > {
> > puts("Exception");
> > }
> > }
> >
> > The potential of such a bug is discussed long time ago in mail:
> > https://gcc.gnu.org/ml/gcc/2007-08/msg00235.html. Basically, as the ARM
> > EHABI does not define how to
> implement
> > the Unwind_Backtrace, Andrew give control to the personality routine to
> > unwind the stack, and use the
> unwind
> > state combination of “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND” to
> > represent that the caller is
> asking the
> > personality routine to only unwind the stack for it.
> >
> > However, the pr in the libstdc++-v3 doesn’t handle such a unwind state
> > pattern correctly. When the backtrace
> > function passes such a pattern to it, it will still return
> > _URC_HANDLER_FOUND to the caller in some cases.
> > It’s because the pr will think that the _Unwind_Backtrace is raising a none
> > type exception to it, so if the
> > exception handler in current stack frame can catch anything(like catch(…)),
> > the pr will return
> > _URC_HANDLER_FOUND to the caller and ask for next step. But definitely, the
> > unwind backtrace function
> don’t
> > know what to do when pr return an exception handler to it.
> >
> > So this patch just evaluate such a unwind state pattern at the beginning of
> > the personality routine in
> > libstdc++-v3, if we meet with “_US_VIRTUAL_UNWIND_FRAME |
> > _US_FORCE_UNWIND”, then we directly call
> macro
> > CONTINUE_UNWINDING to unwind the stack and return.
> >
> > Is this a reasonable fix?
>
> I'd like another review here however it looks sane to me. You need to
> CC libstd...@gcc.gnu.org for libstdc++ patches. Your email doesn't say
> how you tested this patch. Can you make sure you've run this through a
> bootstrap and regression test on GNU/Linux and a cross regression test
> on arm-none-eabi with no regressions ?
Hi Ramana,
Thanks for you review. After this patch, the infinite loop will be fixed for
the above test case, and I can make sure that no regression is happen
during bootstrap and regression test on Linux and a cross regression test
on arm-none-eabi.
Regards,
Tony
>
>
> regards
> Ramana
>
>
>
> >
> > gcc/libstdc++-v3/ChangeLog:
> > 2014-8-25 Tony Wang
> >
> > PR target/56846
> > * libsupc++/eh_personality.cc: Return with
> > CONTINUE_UNWINDING
> > when meet with the unwind state pattern:
> > _US_VIRTUAL_UNWIND_FRAME |
> > _US_FORCE_UNWIND
> >
> > diff --git a/libstdc++-v3/libsupc++/eh_personality.cc
> > b/libstdc++-v3/libsupc++/eh_personality.cc
> > index f315a83..c2b30e9 100644
> > --- a/libstdc++-v3/libsupc++/eh_personality.cc
> > +++ b/libstdc++-v3/libsupc++/eh_personality.cc
> > @@ -378,6 +378,11 @@ PERSONALITY_FUNCTION (int version,
> >switch (state & _US_ACTION_MASK)
> > {
> > case _US_VIRTUAL_UNWIND_FRAME:
> > + // If the unwind state pattern is _US_VIRTUAL_UNWIND_FRAME |
> > + // _US_FORCE_UNWIND, we don't need to search for any handler
> > + // as it is not a real exception. Just unwind the stack.
> > + if (state & _US_FORCE_UNWIND)
> > +CONTINUE_UNWINDING;
> >actions = _UA_SEARCH_PHASE;
> >break;
> >
> >
RE: [Patch ARM] Fix PR target/56846
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Jonathan Wakely
> Sent: Tuesday, September 09, 2014 5:16 PM
> To: Ramana Radhakrishnan
> Cc: Tony Wang; gcc-patches; d...@debian.org; aph-...@littlepinkcloud.com;
> Richard Earnshaw; Ramana
> Radhakrishnan; libstd...@gcc.gnu.org
> Subject: Re: [Patch ARM] Fix PR target/56846
>
> On 09/09/14 09:33 +0100, Ramana Radhakrishnan wrote:
> >I'd like another review here however it looks sane to me. You need to
> >CC libstd...@gcc.gnu.org for libstdc++ patches. Your email doesn't say
> >how you tested this patch. Can you make sure you've run this through a
> >bootstrap and regression test on GNU/Linux and a cross regression test
> >on arm-none-eabi with no regressions ?
>
> Thanks for forwarding this, Ramana.
>
> I don't know the EABI unwinder code so if Ramana is OK with it and no
> other ARM maintainers have any comments then the patch is OK with me
> too, with a couple of small tweaks ...
Thanks for your comment, Jonathan.
I will send a new patch to cover your comment.
BR,
Tony
>
> >>
> >> gcc/libstdc++-v3/ChangeLog:
> >> 2014-8-25 Tony Wang
> >>
> >> PR target/56846
> >> * libsupc++/eh_personality.cc: Return with
> >> CONTINUE_UNWINDING
> >> when meet with the unwind state pattern:
> >> _US_VIRTUAL_UNWIND_FRAME |
> >> _US_FORCE_UNWIND
>
> The changelog should say which function is being changed:
>
> * libsupc++/eh_personality.cc (__gxx_personality_v0): ...
>
> Or maybe:
>
> * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): ...
>
> Instead of "when meet with the unwind state pattern" please say "when the
> state
> pattern contains"
>
> >> diff --git a/libstdc++-v3/libsupc++/eh_personality.cc
> >> b/libstdc++-v3/libsupc++/eh_personality.cc
> >> index f315a83..c2b30e9 100644
> >> --- a/libstdc++-v3/libsupc++/eh_personality.cc
> >> +++ b/libstdc++-v3/libsupc++/eh_personality.cc
> >> @@ -378,6 +378,11 @@ PERSONALITY_FUNCTION (int version,
> >>switch (state & _US_ACTION_MASK)
> >> {
> >> case _US_VIRTUAL_UNWIND_FRAME:
> >> + // If the unwind state pattern is _US_VIRTUAL_UNWIND_FRAME |
> >> + // _US_FORCE_UNWIND, we don't need to search for any handler
> >> + // as it is not a real exception. Just unwind the stack.
>
> I think this comment would be easier to read if the expression with the two
> constants was all on one line:
>
> // If the unwind state pattern is
> // _US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND
> // then we don't need to search for any handler as it is not a real
> // exception. Just unwind the stack.
>
> >> + if (state & _US_FORCE_UNWIND)
> >> +CONTINUE_UNWINDING;
> >>actions = _UA_SEARCH_PHASE;
> >>break;
> >>
> >>
[Patch ARM v2] Fix PR target/56846
Hi there,
This is a updated patch to fix pr56846. Bootstrapped on
x86_64-unknown-linux-gnu and no regression for
regression test on Linux and a cross regression test on arm-none-eabi.
OK for the trunk?
gcc/libstdc++-v3/ChangeLog:
2014-09-09 Tony Wang
PR target/56846
* libsupc++/eh_personality.cc(PERSONALITY_FUNCTION):
Return with CONTINUE_UNWINDING when the state pattern
contains: _US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND
diff --git a/libstdc++-v3/libsupc++/eh_personality.cc
b/libstdc++-v3/libsupc++/eh_personality.cc
index f315a83..836abee 100644
--- a/libstdc++-v3/libsupc++/eh_personality.cc
+++ b/libstdc++-v3/libsupc++/eh_personality.cc
@@ -378,6 +378,12 @@ PERSONALITY_FUNCTION (int version,
switch (state & _US_ACTION_MASK)
{
case _US_VIRTUAL_UNWIND_FRAME:
+ // If the unwind state pattern is
+ // _US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND
+ // then we don't need to search for any handler as it is not a real
+ // exception. Just unwind the stack.
+ if (state & _US_FORCE_UNWIND)
+CONTINUE_UNWINDING;
actions = _UA_SEARCH_PHASE;
break;
RE: [Patch ARM v2] Fix PR target/56846
> -Original Message- > From: Jonathan Wakely [mailto:jwak...@redhat.com] > Sent: Tuesday, September 09, 2014 6:40 PM > To: Tony Wang > Cc: Ramana Radhakrishnan; gcc-patches; libstd...@gcc.gnu.org > Subject: Re: [Patch ARM v2] Fix PR target/56846 > > On 09/09/14 17:47 +0800, Tony Wang wrote: > >Hi there, > > > >This is a updated patch to fix pr56846. Bootstrapped on > >x86_64-unknown-linux-gnu and no regression for > >regression test on Linux and a cross regression test on arm-none-eabi. > > > >OK for the trunk? > > > >gcc/libstdc++-v3/ChangeLog: > >2014-09-09 Tony Wang > > > > PR target/56846 > > * libsupc++/eh_personality.cc(PERSONALITY_FUNCTION): >^ > There should be a space after the file name (look at existing > changelog entries) > > OK with that change. Committed with your comment on trunk, and also tested on 4.9 branch with no regression. So is it ok to back port to 4.9 branch? BR, Tony
RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping?
> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Thursday, September 04, 2014 10:16 AM
> To: 'gcc-patches@gcc.gnu.org'
> Cc: Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv
> and dmul/ddiv function in libgcc
>
> Ping 2?
>
> > -Original Message-
> > From: Tony Wang [mailto:tony.w...@arm.com]
> > Sent: Thursday, August 28, 2014 2:02 PM
> > To: 'gcc-patches@gcc.gnu.org'
> > Cc: Richard Earnshaw; Ramana Radhakrishnan
> > Subject: RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv
> > and dmul/ddiv function in
libgcc
> >
> > Ping?
> >
> > > -Original Message-
> > > From: Tony Wang [mailto:tony.w...@arm.com]
> > > Sent: Thursday, August 21, 2014 2:15 PM
> > > To: 'gcc-patches@gcc.gnu.org'
> > > Subject: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv
> > > and dmul/ddiv function in libgcc
> > >
> > > Step 3: Test cases to verify the code size reduction.
> > >
> > > gcc/gcc/testsuite/ChangeLog:
> > > 2014-08-21 Tony Wang
> > >
> > > * gcc.target/arm/size-optimization-ieee-1.c: New test case
> > > * gcc.target/arm/size-optimization-ieee-2.c: New test case
> > > * lib/gcc-dg.exp: Add new function scan-symbol-common,
> > > scan-symbol-yes,
> > > scan-symbol-no to scan a user defined symbol in final elf file
> > >
> > > BR,
> > > Tony
> > >
> > > diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
b/gcc/testsuite/gcc.target/arm/size-
> > > optimization-ieee-1.c
> > > new file mode 100644
> > > index 000..46e9cdf
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
> > > @@ -0,0 +1,30 @@
> > > +/* { dg-do link { target { arm_thumb2_ok } } } */
> > > +/* { dg-options "-Wl,--gc-sections" } */
> > > +int
> > > +foo ()
> > > +{
> > > + volatile float a;
> > > + volatile float b;
> > > + volatile float c = a * b;
> > > + return 0;
> > > +}
> > > +
> > > +int
> > > +bar ()
> > > +{
> > > + volatile double a;
> > > + volatile double b;
> > > + volatile double c = a * b;
> > > + return 0;
> > > +}
> > > +
> > > +int
> > > +main ()
> > > +{
> > > + foo ();
> > > + bar ();
> > > + return 0;
> > > +}
> > > +/* { dg-final { scan-symbol-no "__aeabi_fdiv" } } */
> > > +/* { dg-final { scan-symbol-no "__aeabi_ddiv" } } */
> > > +
> > > diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
b/gcc/testsuite/gcc.target/arm/size-
> > > optimization-ieee-2.c
> > > new file mode 100644
> > > index 000..5007d62
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
> > > @@ -0,0 +1,30 @@
> > > +/* { dg-do link { target { arm_thumb2_ok } } } */
> > > +/* { dg-options "-Wl,--gc-sections" } */
> > > +int
> > > +foo ()
> > > +{
> > > + volatile float a;
> > > + volatile float b;
> > > + volatile float c = a / b;
> > > + return 0;
> > > +}
> > > +
> > > +int
> > > +bar ()
> > > +{
> > > + volatile double a;
> > > + volatile double b;
> > > + volatile double c = a / b;
> > > + return 0;
> > > +}
> > > +
> > > +int
> > > +main ()
> > > +{
> > > + foo ();
> > > + bar ();
> > > + return 0;
> > > +}
> > > +/* { dg-final { scan-symbol-yes "__aeabi_fmul" } } */
> > > +/* { dg-final { scan-symbol-yes "__aeabi_dmul" } } */
> > > +
> > > diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> > > index 3390caa..0d52e95 100644
> > > --- a/gcc/testsuite/lib/gcc-dg.exp
> > > +++ b/gcc/testsuite/lib/gcc-dg.exp
> > > @@ -880,5 +880,57 @@ proc gdb-exists { args } {
> > > return 0;
> > > }
> > >
> > > +# Scan the OUTPUT_FILE for a symbol. Return 1 if it present, or
> > > +# return 0 if it doesn't present
> > > +
> > > +proc scan-symbol-common { args } {
> > > +global nm
&
RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping? > -Original Message- > From: Tony Wang [mailto:tony.w...@arm.com] > Sent: Thursday, September 04, 2014 10:15 AM > To: 'gcc-patches@gcc.gnu.org' > Cc: Richard Earnshaw; Ramana Radhakrishnan > Subject: RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv > and dmul/ddiv function in libgcc > > Ping 2? > > > -Original Message- > > From: Tony Wang [mailto:tony.w...@arm.com] > > Sent: Thursday, August 28, 2014 2:02 PM > > To: 'gcc-patches@gcc.gnu.org' > > Cc: Richard Earnshaw; Ramana Radhakrishnan > > Subject: RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv > > and dmul/ddiv function in libgcc > > > > Ping? > > > > > -Original Message- > > > From: Tony Wang [mailto:tony.w...@arm.com] > > > Sent: Thursday, August 21, 2014 2:15 PM > > > To: 'gcc-patches@gcc.gnu.org' > > > Subject: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv > > > and dmul/ddiv function in libgcc > > > > > > Hi there, > > > > > > In libgcc the file ieee754-sf.S and ieee754-df.S have some function pairs > > > which will be bundled into one .o file > > and > > > sharing the same .text section. For example, the fmul and fdiv, the > > > libgcc makefile will build them into one .o > > file > > > and archived into libgcc.a. So when user only call single float point > > > multiply functions, the fdiv function will > also > > be > > > linked, and as fmul and fdiv share the same .text section, linker option > > > --gc-sections or -flot can't remove the > > > dead code. > > > > > > So this optimization just separates the function pair(fmul/fdiv and > > > dmul/ddiv) into different sections, > following > > > the naming pattern of -ffunction-sections(.text.__functionname), through > > > which the unused sections of > > > fdiv/ddiv can be eliminated through option --gcc-sections when users only > > > use fmul/dmul.The solution is to > > add > > > a conditional statement in the macro FUNC_START, which will conditional > > > change the section of a function > > > from .text to .text.__\name. when compiling with the L_arm_muldivsf3 or > > > L_arm_muldivdf3 macro. > > > > > > GCC regression test has been done on QEMU for Cortex-M3. No new > > > regressions when turn on this patch. > > > > > > The code reduction for thumb2 on cortex-m3 is: > > > 1. When user only use single float point multiply: > > > fmul+fdiv => fmul will have a code size reduction of 318 bytes. > > > > > > 2. When user only use double float point multiply: > > > dmul+ddiv => dmul will have a code size reduction of 474 bytes. > > > > > > Ok for trunk? > > > > > > BR, > > > Tony > > > > > > Step 1: Provide another option: sp-scetion to control whether to split > > > the section of a function pair into two > > part. > > > > > > gcc/libgcc/ChangeLog: > > > 2014-08-21 Tony Wang > > > > > > * config/arm/lib1funcs.S (FUNC_START): Add conditional section > > > redefine for macro L_arm_muldivsf3 and L_arm_muldivdf3 > > > (SYM_END, ARM_SYM_START): Add macros used to expose function > > > Symbols > > > > > > diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S > > > index b617137..0f87111 100644 > > > --- a/libgcc/config/arm/lib1funcs.S > > > +++ b/libgcc/config/arm/lib1funcs.S > > > @@ -418,8 +418,12 @@ SYM (\name): > > > #define THUMB_SYNTAX > > > #endif > > > > > > -.macro FUNC_START name > > > +.macro FUNC_START name sp_section= > > > + .ifc \sp_section, function_section > > > + .section.text.__\name,"ax",%progbits > > > + .else > > > .text > > > + .endif > > > .globl SYM (__\name) > > > TYPE (__\name) > > > .align 0 > > > @@ -429,14 +433,24 @@ SYM (\name): > > > SYM (__\name): > > > .endm > > > > > > +.macro ARM_SYM_START name > > > + TYPE (\name) > > > + .align 0 > > > +SYM (\name): > > > +.endm > > > + > > > +.macro SYM_END name > > > + SIZE (\name) > > > +.endm > > > + > > > /* Special function that will always be coded in ARM assembly, even if > > > in Thumb-only compilation. */ > > > > > > #if defined(__thumb2__) > > > > > > /* For Thumb-2 we build everything in thumb mode. */ > > > -.macro ARM_FUNC_START name > > > - FUNC_START \name > > > +.macro ARM_FUNC_START name sp_section= > > > + FUNC_START \name \sp_section > > > .syntax unified > > > .endm > > > #define EQUIV .thumb_set > > > @@ -467,8 +481,12 @@ _L__\name: > > > #ifdef __ARM_ARCH_6M__ > > > #define EQUIV .thumb_set > > > #else > > > -.macro ARM_FUNC_START name > > > +.macro ARM_FUNC_START name sp_section= > > > + .ifc \sp_section, function_section > > > + .section.text.__\name,"ax",%progbits > > > + .else > > > .text > > > + .endif > > > .globl SYM (__\name) > > > TYPE (__\name) > > > .align 0
RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping? > -Original Message- > From: Tony Wang [mailto:tony.w...@arm.com] > Sent: Thursday, September 04, 2014 10:16 AM > To: 'gcc-patches@gcc.gnu.org' > Cc: Richard Earnshaw; Ramana Radhakrishnan > Subject: RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv > and dmul/ddiv function in libgcc > > Ping 2? > > > -Original Message- > > From: Tony Wang [mailto:tony.w...@arm.com] > > Sent: Thursday, August 28, 2014 2:02 PM > > To: 'gcc-patches@gcc.gnu.org' > > Cc: Richard Earnshaw; Ramana Radhakrishnan > > Subject: RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv > > and dmul/ddiv function in libgcc > > > > Ping? > > > > > -Original Message- > > > From: Tony Wang [mailto:tony.w...@arm.com] > > > Sent: Thursday, August 21, 2014 2:15 PM > > > To: 'gcc-patches@gcc.gnu.org' > > > Subject: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv > > > and dmul/ddiv function in libgcc > > > > > > Step 2: Mark all the symbols around the fragment boundaries as function > > > symbols, so as to generate veneer > > > when the two section is too far away from each other. Also, I have both > > > manually and using some test cases > to > > > verify that IP and PSR are not alive at such point. > > > > > > gcc/libgcc/ChangeLog: > > > 2014-8-21 Tony Wang > > > > > > * config/arm/ieee754-sf.S: Expose symbols around fragment > > > boundaries as function symbols. > > > * config/arm/ieee754-df.S: Same with above > > > > > > BR, > > > Tony
RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping? > -Original Message- > From: Tony Wang [mailto:tony.w...@arm.com] > Sent: Tuesday, September 16, 2014 11:01 AM > To: 'gcc-patches@gcc.gnu.org' > Cc: Richard Earnshaw; Ramana Radhakrishnan > Subject: RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv > and dmul/ddiv function in libgcc > > Ping? > > > -Original Message- > > From: Tony Wang [mailto:tony.w...@arm.com] > > Sent: Thursday, September 04, 2014 10:15 AM > > To: 'gcc-patches@gcc.gnu.org' > > Cc: Richard Earnshaw; Ramana Radhakrishnan > > Subject: RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv > > and dmul/ddiv function in libgcc > > > > Ping 2? > > > > > -Original Message- > > > From: Tony Wang [mailto:tony.w...@arm.com] > > > Sent: Thursday, August 28, 2014 2:02 PM > > > To: 'gcc-patches@gcc.gnu.org' > > > Cc: Richard Earnshaw; Ramana Radhakrishnan > > > Subject: RE: [PATCH 1/3,ARM,libgcc]Code size optimization for the > > > fmul/fdiv and dmul/ddiv function in libgcc > > > > > > Ping? > > > > > > > -Original Message- > > > > From: Tony Wang [mailto:tony.w...@arm.com] > > > > Sent: Thursday, August 21, 2014 2:15 PM > > > > To: 'gcc-patches@gcc.gnu.org' > > > > Subject: [PATCH 1/3,ARM,libgcc]Code size optimization for the fmul/fdiv > > > > and dmul/ddiv function in libgcc > > > > > > > > Hi there, > > > > > > > > In libgcc the file ieee754-sf.S and ieee754-df.S have some function > > > > pairs which will be bundled into one .o > file > > > and > > > > sharing the same .text section. For example, the fmul and fdiv, the > > > > libgcc makefile will build them into > one .o > > > file > > > > and archived into libgcc.a. So when user only call single float point > > > > multiply functions, the fdiv function will > > also > > > be > > > > linked, and as fmul and fdiv share the same .text section, linker > > > > option --gc-sections or -flot can't remove > the > > > > dead code. > > > > > > > > So this optimization just separates the function pair(fmul/fdiv and > > > > dmul/ddiv) into different sections, > > following > > > > the naming pattern of -ffunction-sections(.text.__functionname), > > > > through which the unused sections of > > > > fdiv/ddiv can be eliminated through option --gcc-sections when users > > > > only use fmul/dmul.The solution is to > > > add > > > > a conditional statement in the macro FUNC_START, which will conditional > > > > change the section of a function > > > > from .text to .text.__\name. when compiling with the L_arm_muldivsf3 or > > > > L_arm_muldivdf3 macro. > > > > > > > > GCC regression test has been done on QEMU for Cortex-M3. No new > > > > regressions when turn on this patch. > > > > > > > > The code reduction for thumb2 on cortex-m3 is: > > > > 1. When user only use single float point multiply: > > > > fmul+fdiv => fmul will have a code size reduction of 318 bytes. > > > > > > > > 2. When user only use double float point multiply: > > > > dmul+ddiv => dmul will have a code size reduction of 474 bytes. > > > > > > > > Ok for trunk? > > > > > > > > BR, > > > > Tony > > > > > > > > Step 1: Provide another option: sp-scetion to control whether to split > > > > the section of a function pair into two > > > part. > > > > > > > > gcc/libgcc/ChangeLog: > > > > 2014-08-21 Tony Wang > > > > > > > > * config/arm/lib1funcs.S (FUNC_START): Add conditional section > > > > redefine for macro L_arm_muldivsf3 and L_arm_muldivdf3 > > > > (SYM_END, ARM_SYM_START): Add macros used to expose function > > > > Symbols > > > > > > > > diff --git a/libgcc/config/arm/lib1funcs.S > > > > b/libgcc/config/arm/lib1funcs.S > > > > index b617137..0f87111 100644 > > > > --- a/libgcc/config/arm/lib1funcs.S > > > > +++ b/libgcc/config/arm/lib1funcs.S > > > > @@ -418,8 +418,12 @@ SYM (\name): > > > > #define THUMB_SYNTAX > > > > #endif > > > > > >
RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping? > -Original Message- > From: Tony Wang [mailto:tony.w...@arm.com] > Sent: Tuesday, September 16, 2014 11:01 AM > To: 'gcc-patches@gcc.gnu.org' > Cc: Richard Earnshaw; Ramana Radhakrishnan > Subject: RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv > and dmul/ddiv function in libgcc > > Ping? > > > -Original Message- > > From: Tony Wang [mailto:tony.w...@arm.com] > > Sent: Thursday, September 04, 2014 10:16 AM > > To: 'gcc-patches@gcc.gnu.org' > > Cc: Richard Earnshaw; Ramana Radhakrishnan > > Subject: RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv > > and dmul/ddiv function in libgcc > > > > Ping 2? > > > > > -Original Message- > > > From: Tony Wang [mailto:tony.w...@arm.com] > > > Sent: Thursday, August 28, 2014 2:02 PM > > > To: 'gcc-patches@gcc.gnu.org' > > > Cc: Richard Earnshaw; Ramana Radhakrishnan > > > Subject: RE: [PATCH 2/3,ARM,libgcc]Code size optimization for the > > > fmul/fdiv and dmul/ddiv function in libgcc > > > > > > Ping? > > > > > > > -Original Message- > > > > From: Tony Wang [mailto:tony.w...@arm.com] > > > > Sent: Thursday, August 21, 2014 2:15 PM > > > > To: 'gcc-patches@gcc.gnu.org' > > > > Subject: [PATCH 2/3,ARM,libgcc]Code size optimization for the fmul/fdiv > > > > and dmul/ddiv function in libgcc > > > > > > > > Step 2: Mark all the symbols around the fragment boundaries as function > > > > symbols, so as to generate > veneer > > > > when the two section is too far away from each other. Also, I have both > > > > manually and using some test > cases > > to > > > > verify that IP and PSR are not alive at such point. > > > > > > > > gcc/libgcc/ChangeLog: > > > > 2014-8-21 Tony Wang > > > > > > > > * config/arm/ieee754-sf.S: Expose symbols around fragment > > > > boundaries as function symbols. > > > > * config/arm/ieee754-df.S: Same with above > > > > > > > > BR, > > > > Tony
RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
Ping?
> -Original Message-
> From: Tony Wang [mailto:tony.w...@arm.com]
> Sent: Tuesday, September 16, 2014 11:01 AM
> To: 'gcc-patches@gcc.gnu.org'
> Cc: Richard Earnshaw; Ramana Radhakrishnan
> Subject: RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv
> and dmul/ddiv function in libgcc
>
> Ping?
>
> > -Original Message-
> > From: Tony Wang [mailto:tony.w...@arm.com]
> > Sent: Thursday, September 04, 2014 10:16 AM
> > To: 'gcc-patches@gcc.gnu.org'
> > Cc: Richard Earnshaw; Ramana Radhakrishnan
> > Subject: RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv
> > and dmul/ddiv function in
libgcc
> >
> > Ping 2?
> >
> > > -Original Message-
> > > From: Tony Wang [mailto:tony.w...@arm.com]
> > > Sent: Thursday, August 28, 2014 2:02 PM
> > > To: 'gcc-patches@gcc.gnu.org'
> > > Cc: Richard Earnshaw; Ramana Radhakrishnan
> > > Subject: RE: [PATCH 3/3,ARM,libgcc]Code size optimization for the
> > > fmul/fdiv and dmul/ddiv function in
libgcc
> > >
> > > Ping?
> > >
> > > > -Original Message-
> > > > From: Tony Wang [mailto:tony.w...@arm.com]
> > > > Sent: Thursday, August 21, 2014 2:15 PM
> > > > To: 'gcc-patches@gcc.gnu.org'
> > > > Subject: [PATCH 3/3,ARM,libgcc]Code size optimization for the fmul/fdiv
> > > > and dmul/ddiv function in
libgcc
> > > >
> > > > Step 3: Test cases to verify the code size reduction.
> > > >
> > > > gcc/gcc/testsuite/ChangeLog:
> > > > 2014-08-21 Tony Wang
> > > >
> > > > * gcc.target/arm/size-optimization-ieee-1.c: New test case
> > > > * gcc.target/arm/size-optimization-ieee-2.c: New test case
> > > > * lib/gcc-dg.exp: Add new function scan-symbol-common,
> > > > scan-symbol-yes,
> > > > scan-symbol-no to scan a user defined symbol in final elf file
> > > >
> > > > BR,
> > > > Tony
> > > >
> > > > diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
b/gcc/testsuite/gcc.target/arm/size-
> > > > optimization-ieee-1.c
> > > > new file mode 100644
> > > > index 000..46e9cdf
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
> > > > @@ -0,0 +1,30 @@
> > > > +/* { dg-do link { target { arm_thumb2_ok } } } */
> > > > +/* { dg-options "-Wl,--gc-sections" } */
> > > > +int
> > > > +foo ()
> > > > +{
> > > > + volatile float a;
> > > > + volatile float b;
> > > > + volatile float c = a * b;
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int
> > > > +bar ()
> > > > +{
> > > > + volatile double a;
> > > > + volatile double b;
> > > > + volatile double c = a * b;
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int
> > > > +main ()
> > > > +{
> > > > + foo ();
> > > > + bar ();
> > > > + return 0;
> > > > +}
> > > > +/* { dg-final { scan-symbol-no "__aeabi_fdiv" } } */
> > > > +/* { dg-final { scan-symbol-no "__aeabi_ddiv" } } */
> > > > +
> > > > diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
b/gcc/testsuite/gcc.target/arm/size-
> > > > optimization-ieee-2.c
> > > > new file mode 100644
> > > > index 000..5007d62
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
> > > > @@ -0,0 +1,30 @@
> > > > +/* { dg-do link { target { arm_thumb2_ok } } } */
> > > > +/* { dg-options "-Wl,--gc-sections" } */
> > > > +int
> > > > +foo ()
> > > > +{
> > > > + volatile float a;
> > > > + volatile float b;
> > > > + volatile float c = a / b;
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int
> > > > +bar ()
> > > > +{
> > > > + volatile double a;
> > > > + volatile double b;
> > > > + volatile double c = a / b;
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int
> > &
[Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
Hi there,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330.
There will be an ICE in gcc trunk for targets support section anchor
optimization when compiling this case(like arm and mips). This looks like an
old bug which is exposed by recent patch.
In make_decl_rtl, when you declare register type incorrectly like "register
int *a asm("unknown register");", the compiler will raise an error messge
but doesn't return directly. It will continue to run into the rtx generation
code for general variable declaration and generate a wrong
rtx:(symbol_ref:SI...). So I just remove the else condition which used to be
the rtx generation part for correctly declared register type, and let all
the register type declaration(no matter it declared correct or not) go
through it and generate the same type of rtx:(reg:SI...).
gcc/ChangeLog:
2014-07-29 Tony Wang tony.w...@arm.com
* gcc/varasm.c (make_decl_rtl): Remove the else condition
for properly declared static register variables.
diff --git a/gcc/varasm.c b/gcc/varasm.c index 819ec26..a6fae0c 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -1333,45 +1333,42 @@ make_decl_rtl (tree decl)
error ("register specified for %q+D isn%'t suitable for data
type",
decl);
/* Now handle properly declared static register variables. */
- else
- {
-int nregs;
+ int nregs;
-if (DECL_INITIAL (decl) != 0 && TREE_STATIC (decl))
- {
-DECL_INITIAL (decl) = 0;
-error ("global register variable has initial value");
- }
-if (TREE_THIS_VOLATILE (decl))
- warning (OPT_Wvolatile_register_var,
- "optimization may eliminate reads and/or
"
- "writes to register variables");
+ if (DECL_INITIAL (decl) != 0 && TREE_STATIC (decl))
+{
+ DECL_INITIAL (decl) = 0;
+ error ("global register variable has initial value");
+}
+ if (TREE_THIS_VOLATILE (decl))
+warning (OPT_Wvolatile_register_var,
+ "optimization may eliminate reads and/or "
+ "writes to register variables");
-/* If the user specified one of the eliminables registers
here,
- e.g., FRAME_POINTER_REGNUM, we don't want to get this
variable
- confused with that register and be eliminated. This
usage is
- somewhat suspect... */
+ /* If the user specified one of the eliminables registers here,
+ e.g., FRAME_POINTER_REGNUM, we don't want to get this variable
+ confused with that register and be eliminated. This usage is
+ somewhat suspect... */
-SET_DECL_RTL (decl, gen_rtx_raw_REG (mode, reg_number));
-ORIGINAL_REGNO (DECL_RTL (decl)) = reg_number;
-REG_USERVAR_P (DECL_RTL (decl)) = 1;
+ SET_DECL_RTL (decl, gen_rtx_raw_REG (mode, reg_number));
+ ORIGINAL_REGNO (DECL_RTL (decl)) = reg_number;
+ REG_USERVAR_P (DECL_RTL (decl)) = 1;
-if (TREE_STATIC (decl))
- {
-/* Make this register global, so not usable for
anything
- else. */
+ if (TREE_STATIC (decl))
+{
+ /* Make this register global, so not usable for anything
+ else. */
#ifdef ASM_DECLARE_REGISTER_GLOBAL
-name = IDENTIFIER_POINTER (DECL_NAME (decl));
-ASM_DECLARE_REGISTER_GLOBAL (asm_out_file, decl,
reg_number, name);
+ name = IDENTIFIER_POINTER (DECL_NAME (decl));
+ ASM_DECLARE_REGISTER_GLOBAL (asm_out_file, decl, reg_number,
+ name);
#endif
-nregs = hard_regno_nregs[reg_number][mode];
-while (nregs > 0)
- globalize_reg (decl, reg_number + --nregs);
- }
+ nregs = hard_regno_nregs[reg_number][mode];
+ while (nregs > 0)
+globalize_reg (decl, reg_number + --nregs);
+}
-/* As a register variable, it has no section. */
-return;
- }
+ /* As a register variable, it has no section. */
+ return;
}
/* Now handle ordinary static variables and functions (in memory).
Also handle vars declared register invalidly. */
BR,
Tony
920507.diff
Description: Binary data
[PING][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
Ping, any comment and suggestion on this bug fix?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tony Wang
> Sent: Tuesday, July 29, 2014 10:31 AM
> To: gcc-patches@gcc.gnu.org; 'Richard Biener'; 'Jakub Jelinek'
> Subject: [Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
>
> Hi there,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330.
> There will be an ICE in gcc trunk for targets support section anchor
> optimization when compiling this case(like arm and mips). This looks like
an
The target should be aarch64, arm, powerpc, alpha
> old bug which is exposed by recent patch.
>
> In make_decl_rtl, when you declare register type incorrectly like
"register int
> *a asm("unknown register");", the compiler will raise an error messge but
> doesn't return directly. It will continue to run into the rtx generation
code for
> general variable declaration and generate a wrong rtx:(symbol_ref:SI...).
So I
> just remove the else condition which used to be the rtx generation part
for
> correctly declared register type, and let all the register type
declaration(no
> matter it declared correct or not) go through it and generate the same
type
> of rtx:(reg:SI...).
>
> gcc/ChangeLog:
>
> 2014-07-29 Tony Wang tony.w...@arm.com
>
> * gcc/varasm.c (make_decl_rtl): Remove the else condition
> for properly declared static register variables.
>
> diff --git a/gcc/varasm.c b/gcc/varasm.c index 819ec26..a6fae0c 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -1333,45 +1333,42 @@ make_decl_rtl (tree decl)
>error ("register specified for %q+D isn%'t suitable for
data type",
> decl);
>/* Now handle properly declared static register variables. */
> - else
> - {
> -int nregs;
> + int nregs;
>
> -if (DECL_INITIAL (decl) != 0 && TREE_STATIC (decl))
> - {
> -DECL_INITIAL (decl) = 0;
> -error ("global register variable has initial value");
> - }
> -if (TREE_THIS_VOLATILE (decl))
> - warning (OPT_Wvolatile_register_var,
> - "optimization may eliminate reads
and/or
> "
> - "writes to register variables");
> + if (DECL_INITIAL (decl) != 0 && TREE_STATIC (decl))
> +{
> + DECL_INITIAL (decl) = 0;
> + error ("global register variable has initial value");
> +}
> + if (TREE_THIS_VOLATILE (decl))
> +warning (OPT_Wvolatile_register_var,
> + "optimization may eliminate reads and/or "
> + "writes to register variables");
>
> -/* If the user specified one of the eliminables registers
> here,
> - e.g., FRAME_POINTER_REGNUM, we don't want to get this
> variable
> - confused with that register and be eliminated. This
> usage is
> - somewhat suspect... */
> + /* If the user specified one of the eliminables registers here,
> + e.g., FRAME_POINTER_REGNUM, we don't want to get this variable
> + confused with that register and be eliminated. This usage is
> + somewhat suspect... */
>
> -SET_DECL_RTL (decl, gen_rtx_raw_REG (mode, reg_number));
> -ORIGINAL_REGNO (DECL_RTL (decl)) = reg_number;
> -REG_USERVAR_P (DECL_RTL (decl)) = 1;
> + SET_DECL_RTL (decl, gen_rtx_raw_REG (mode, reg_number));
> + ORIGINAL_REGNO (DECL_RTL (decl)) = reg_number;
> + REG_USERVAR_P (DECL_RTL (decl)) = 1;
>
> -if (TREE_STATIC (decl))
> - {
> -/* Make this register global, so not usable for
> anything
> - else. */
> + if (TREE_STATIC (decl))
> +{
> + /* Make this register global, so not usable for anything
> + else. */
> #ifdef ASM_DECLARE_REGISTER_GLOBAL
> -name = IDENTIFIER_POINTER (DECL_NAME (decl));
> -ASM_DECLARE_REGISTER_GLOBAL (asm_out_file, decl,
> reg_number, name);
> + name = IDENTIFIER_POINTER (DECL_NAME (decl));
> + ASM_DECLARE_REGISTER_GLOBAL (asm_out_file, decl, reg_number,
> + name);
> #endif
> -nregs = hard_regno_nregs[reg_number][mode];
> -while (nregs > 0)
> -
