Expansion of memset and memcpy calls.
Hello All: Memset and Memcpy calls are extensively used in many benchmarks. Inlining or expansion the memcpy and memset calls improves the performance of many performance Benchmark. I have implemented the expansion of strcmp to the optimizaed sequence of instruction In open64 compiler for AMD x86 target. Can I suggest and propose to expand the memset and memcpy calls to the sequence Of instruction as many targets like ARM are moving implementation of memcpy and Memset in assembly instead of C. This makes it easier to expand the memcpy and Memset call in gcc. To implement this in GCC we need to expand similarly to the implementation as builtins. Let me know what do you think. Thanks & Regards Ajit
Re: Expansion of memset and memcpy calls.
On 21/10/14 08:37, Ajit Kumar Agarwal wrote: Hello All: Memset and Memcpy calls are extensively used in many benchmarks. Inlining or expansion the memcpy and memset calls improves the performance of many performance Benchmark. I have implemented the expansion of strcmp to the optimizaed sequence of instruction In open64 compiler for AMD x86 target. Can I suggest and propose to expand the memset and memcpy calls to the sequence Of instruction as many targets like ARM are moving implementation of memcpy and Memset in assembly instead of C. This makes it easier to expand the memcpy and Memset call in gcc. There is the 'movmem' standard name that backends can expand to implement memcpy semantics. For aarch64, for example, look at the movmemdi pattern in aarch64.md and the aarch64_expand_movmem helper in aarch64.c Kyrill To implement this in GCC we need to expand similarly to the implementation as builtins. Let me know what do you think. Thanks & Regards Ajit
[PATCH, fixincludes]: Add pthread.h to glibc_c99_inline_4 fix
On Thu, Oct 16, 2014 at 2:05 PM, Jakub Jelinek wrote:
>> > Recent change caused bootstrap failure on CentOS 5.11:
>> >
>> > /usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only
>> > handles version 2 information.
>> > unwind-dw2-fde-dip_s.o: In function `__pthread_cleanup_routine':
>> > unwind-dw2-fde-dip.c:(.text+0x1590): multiple definition of
>> > `__pthread_cleanup_routine'
>> > /usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only
>> > handles version 2 information.
>> > unwind-dw2_s.o:unwind-dw2.c:(.text+0x270): first defined here
>> > /usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only
>> > handles version 2 information.
>> > unwind-sjlj_s.o: In function `__pthread_cleanup_routine':
>> > unwind-sjlj.c:(.text+0x0): multiple definition of
>> > `__pthread_cleanup_routine'
>> > unwind-dw2_s.o:unwind-dw2.c:(.text+0x270): first defined here
>> > /usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only
>> > handles version 2 information.
>> > emutls_s.o: In function `__pthread_cleanup_routine':
>> > emutls.c:(.text+0x170): multiple definition of `__pthread_cleanup_routine'
>> > unwind-dw2_s.o:unwind-dw2.c:(.text+0x270): first defined here
>> > collect2: error: ld returned 1 exit status
>> > gmake[5]: *** [libgcc_s.so] Error 1
>> >
>> > $ ld --version
>> > GNU ld version 2.17.50.0.6-26.el5 20061020
>>
>> It looks like a switch-to-c11 fallout. Older glibc versions have
>> issues with c99 (and c11) conformance [1].
>>
>> Changing "extern __inline void __pthread_cleanup_routine (...)" in
>> system /usr/include/pthread.h to
>>
>> if __STDC_VERSION__ < 199901L
>> extern
>> #endif
>> __inline__ void __pthread_cleanup_routine (...)
>>
>> fixes this issue and allows bootstrap to proceed.
>>
>> However, fixincludes is not yet built in stage1 bootstrap. Is there a
>> way to fix this issue without changing system headers?
>>
>> [1] https://gcc.gnu.org/ml/gcc-patches/2006-11/msg01030.html
>
> Yeah, old glibcs are totally incompatible with -fno-gnu89-inline.
> Not sure if it is easily fixincludable, if yes, then -fgnu89-inline should
> be used for code like libgcc which is built with the newly built compiler
> before it is fixincluded.
> Or we need -fgnu89-inline by default for old glibcs (that is pretty
> much what we do e.g. in Developer Toolset for RHEL5).
At the end of the day, adding pthread.h to glibc_c99_inline_4 fix
fixes the bootstrap. The fix applies __attribute__((__gnu_inline__))
to the declaration:
extern __inline __attribute__ ((__gnu_inline__)) void
__pthread_cleanup_routine (struct __pthread_cleanup_frame *__frame)
2014-10-21 Uros Bizjak
* inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
* fixincl.x: Regenerate.
Bootstrapped and regression tested on CentOS 5.11 x86_64-linux-gnu {,-m32}.
OK for mainline?
Uros.
Index: fixincl.x
===
--- fixincl.x (revision 216501)
+++ fixincl.x (working copy)
@@ -2,11 +2,11 @@
*
* DO NOT EDIT THIS FILE (fixincl.x)
*
- * It has been AutoGen-ed August 12, 2014 at 02:09:58 PM by AutoGen 5.12
+ * It has been AutoGen-ed October 21, 2014 at 10:18:16 AM by AutoGen 5.16.2
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Tue Aug 12 14:09:58 MSK 2014
+/* DO NOT SVN-MERGE THIS FILE, EITHER Tue Oct 21 10:18:17 CEST 2014
*
* You must regenerate it. Use the ./genfixes script.
*
@@ -3173,7 +3173,7 @@
* File name selection pattern
*/
tSCC zGlibc_C99_Inline_4List[] =
- "sys/sysmacros.h\0*/sys/sysmacros.h\0wchar.h\0*/wchar.h\0";
+
"sys/sysmacros.h\0*/sys/sysmacros.h\0wchar.h\0*/wchar.h\0pthread.h\0*/pthread.h\0";
/*
* Machine/OS name selection pattern
*/
Index: inclhack.def
===
--- inclhack.def(revision 216501)
+++ inclhack.def(working copy)
@@ -1687,7 +1687,8 @@
*/
fix = {
hackname = glibc_c99_inline_4;
-files = sys/sysmacros.h, '*/sys/sysmacros.h', wchar.h, '*/wchar.h';
+files = sys/sysmacros.h, '*/sys/sysmacros.h', wchar.h, '*/wchar.h',
+pthread.h, '*/pthread.h';
bypass= "__extern_inline|__gnu_inline__";
select= "(^| )extern __inline";
c_fix = format;
Re: [PATCH, fixincludes]: Add pthread.h to glibc_c99_inline_4 fix
On Tue, Oct 21, 2014 at 11:30:49AM +0200, Uros Bizjak wrote:
> At the end of the day, adding pthread.h to glibc_c99_inline_4 fix
> fixes the bootstrap. The fix applies __attribute__((__gnu_inline__))
> to the declaration:
>
> extern __inline __attribute__ ((__gnu_inline__)) void
> __pthread_cleanup_routine (struct __pthread_cleanup_frame *__frame)
>
> 2014-10-21 Uros Bizjak
>
> * inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
> * fixincl.x: Regenerate.
>
> Bootstrapped and regression tested on CentOS 5.11 x86_64-linux-gnu {,-m32}.
>
> OK for mainline?
Ok, thanks.
> --- inclhack.def (revision 216501)
> +++ inclhack.def (working copy)
> @@ -1687,7 +1687,8 @@
> */
> fix = {
> hackname = glibc_c99_inline_4;
> -files = sys/sysmacros.h, '*/sys/sysmacros.h', wchar.h, '*/wchar.h';
> +files = sys/sysmacros.h, '*/sys/sysmacros.h', wchar.h, '*/wchar.h',
> +pthread.h, '*/pthread.h';
> bypass= "__extern_inline|__gnu_inline__";
> select= "(^| )extern __inline";
> c_fix = format;
Jakub
m32c libgcc SJLJ detection in libgcc
Hi It looks like the check for SJLJ use by a target starting at line 211 in libgcc/configure.ac does not take into account whether the build included a language that needs this. For RTEMS, we build m32c with only C and this check not being guarded results in needing to provide --disable-sjlj-exceptions on the configure line. Before we didn't have to do this. FWIW I think this same issue is tripped by the h8300. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
RFA: Add avrtiny support
In __do_global_dtors, I ended up changing the order of execution in order to get back to the forwards/backwards order as found in crtstuff.c The patch I attached to target/63223 is actually an extract from this patch. gcc: 2014-08-29 Joern Rennecke Vidya Praveen Praveen Kumar Kaushik Senthil Kumar Selvaraj Pitchumani Sivanupandi * config/avr/avr-c.c (avr_cpu_cpp_builtins): Don't define __MEMX for avrtiny. * config/avr/avr.c (avr_insert_attributes): Reject __memx for avrtiny. (avr_nonconst_pointer_addrspace): Likewise. * config/avr/avr.h (AVR_HAVE_LPM): Define. Added AVRTINY architecture to avr target. * config/avr/avr-arch.h (avr_arch): Added AVRTINY architecture. (base_arch_s): member added for AVRTINY architecture. * config/avr/avr.c: Added TINY_ADIW, TINY_SBIW macros as AVRTINY alternate for adiw/sbiw instructions. Added AVR_TMP_REGNO and AVR_ZERO_REGNO macros for tmp and zero registers. Replaced TMP_REGNO and ZERO_REGNO occurrences by AVR_TMP_REGNO and AVR_ZERO_REGNO respectively. LAST_CALLEE_SAVED_REG macro added for the last register in callee saved register list. (avr_option_override): CCP address updated for AVRTINY. (avr_init_expanders): tmp and zero rtx initialized as per arch. Reset avr_have_dimode if AVRTINY. (sequent_regs_live): Use LAST_CALLEE_SAVED_REG instead magic number. (emit_push_sfr): Use AVR_TMP_REGNO for tmp register number. (avr_prologue_setup_frame): Don't minimize prologue if AVRTINY. Use LAST_CALLEE_SAVED_REG to refer last callee saved register. (expand_epilogue): Likewise. (avr_print_operand): Print CCP address in case of AVRTINY also. bad address (function_arg_regno_p): Check different register list for arguments if AVRTINY. (init_cumulative_args): Check for AVRTINY to update number of argument registers. (tiny_valid_direct_memory_access_range): New function. Return false if direct memory access range is not in accepted range for AVRTINY. (avr_out_movqi_r_mr_reg_disp_tiny): New function to handle register indirect load (with displacement) for AVRTINY. (out_movqi_r_mr): Updated instruction length for AVRTINY. Call avr_out_movqi_r_mr_reg_disp_tiny for load from reg+displacement. (avr_out_movhi_r_mr_reg_no_disp_tiny): New function to handle register indirect load (no displacement) for AVRTINY. (avr_out_movhi_r_mr_reg_disp_tiny): New function to handle register indirect load (with displacement) for AVRTINY. (avr_out_movhi_r_mr_pre_dec_tiny): New function to handle register indirect load for pre-decrement address. (out_movhi_r_mr): In case of AVRTINY, call tiny register indirect load functions. Update instruction length for AVRTINY. (avr_out_movsi_r_mr_reg_no_disp_tiny): New function. Likewise, for SImode. (avr_out_movsi_r_mr_reg_disp_tiny): New function. Likewise, for SImode. (out_movsi_r_mr): Likewise, for SImode. (avr_out_movsi_mr_r_reg_no_disp_tiny): New function to handle register indirect store (no displacement) for AVRTINY. (avr_out_movsi_mr_r_reg_disp_tiny): New function to handle register indirect store (with displacement) for AVRTINY. (out_movsi_mr_r): Emit out insn for IO address store. Update store instruction's size for AVRTINY. For AVRTINY, call tiny SImode indirect store functions. (avr_out_load_psi_reg_no_disp_tiny): New function to handle register indirect load (no displacement) for PSImode in AVRTINY. (avr_out_load_psi_reg_disp_tiny): New function to handle register indirect load (with displacement) for PSImode in AVRTINY. (avr_out_load_psi): Call PSImode register indirect load functions for AVRTINY. Update instruction length for AVRTINY. (avr_out_store_psi_reg_no_disp_tiny): New function to handle register indirect store (no displacement) for PSImode in AVRTINY. (avr_out_store_psi_reg_disp_tiny): New function to handle register indirect store (with displacement) for PSImode in AVRTINY. (avr_out_store_psi): Update instruction length for AVRTINY. Call tiny register indirect store functions for AVRTINY. (avr_out_movqi_mr_r_reg_disp_tiny): New function to handle QImode register indirect store (with displacement) for AVRTINY. (out_movqi_mr_r): Update instruction length for AVRTINY. Call tiny register indirect store function for QImode in AVRTINY. (avr_out_movhi_mr_r_xmega): Update instruction length for AVRTINY. (avr_out_movhi_mr_r_reg_no_disp_tiny): New function to handle register indirect store (no displacement) for HImode in AVRTINY. (a
Re: RFA: Add avrtiny support
2014-10-21 21:18 GMT+04:00 Joern Rennecke : > In __do_global_dtors, I ended up changing the order of execution > in order to get back to the forwards/backwards order as found in > crtstuff.c > The patch I attached to target/63223 is actually an extract from this patch. Approved. Denis.
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 10/15/14 18:07, Chen Gang wrote:
> On 10/13/14 21:18, Chen Gang wrote:
>> On 10/13/14 18:53, Jason Merrill wrote:
>>> On 10/12/2014 10:32 AM, Chen Gang wrote:
[root@localhost qemu_cc]# cat test.cc
const char n() { return 1; }
const char c = n();
[root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O0 -c -o test.o
test.cc
[root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O2 -c -o test.o
test.cc
test.cc:2:12: warning: 'c' defined but not used [-Wunused-variable]
const char c = n();
^
>>>
>>> The warning is correct (and new). Please submit bug reports via the
>>> website; see https://gcc.gnu.org/bugs/
>>>
Aftr trying, I can not make a new account for gcc bugzilla.
- Before file a bug, it is mandatory to have an acount.
- I try to register a new account on the website, it said that need
send mail to overse...@gcc.gnu.org.
- I sent related mail to overse...@gcc.gnu.org, but get no response.
Need I wait for some days? or could any member help to file this bug to
gcc bugzilla?
And whether it is OK or not, I shall try to analyze this issue directly,
I should try to finish it within 2014-10-31 (although I am really not
quite sure about it).
Thanks.
>
> Thank Jason Merrill, again. At present, I have got enough confirmation
> from you and other members (excuse me, I am not quite familiar with C++,
> for me, it is a complex language, so need several members confirmation).
>
> And if no additional reply within this week, I shall submit bug reports,
> and try to fix it within this month (although I am really not quite
> sure).
>
> I am not quite familiar with C++, so if any members worry about me: feel
> that I am not quite suitable to report bug and fix it, please let me
> know within this week.
>
> Thanks.
>
>>
>> OK, thanks. After finish this consult, I shall report bugs, and shall
>> try to fix it (I got it from Qemu which in my current focus border).
>> Hope I can finish within this month.
>>
>> And one another consult: if the constant variable is defined in header
>> file, and never be used, need our g++ still report warning about
>> [-Wunused-variable] too (for me, I guess, not)?
>>
>>
>> Thanks.
>>
>
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
