Re: gcc4.6,how to remove werror
I could not find that WERROR override code at my kernels... Sorry delay it, I did make V=1. There are three kinds test. All targets are ARM. All Makefiles(top of kernel tree)-KBUILD_CFLAGS are same. KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Wno-format-security \ -fno-delete-null-pointer-checks I think linaro Werror behaviour is different or I need to add FLAGS more. Compile CM-kernel with android SDK make -f scripts/Makefile.build obj=drivers/net/wireless/bcm4329 rm -f drivers/net/wireless/bcm4329/built-in.o; /home/tknv/android/Oxygen/prebuil t/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-ar rcs drivers/net/wireless/bcm43 29/built-in.o /home/tknv/android/Oxygen/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eab i-gcc -Wp,-MD,drivers/net/wireless/bcm4329/.dhd_linux.o.d -nostdinc -isystem /home /tknv/android/Oxygen/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm -eabi/4.4.3/include -I/home/tknv/android/SuperSonic/kernels/CM-kernel/arch/arm/incl ude -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian - Iarch/arm/mach-msm/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-st rict-aliasing -fno-common -Wno-format-security -fno-delete-null-pointer-checks -Os -marm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -f omit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-over flow -fno-dwarf2-cfi-asm -fconserve-stack -DLINUX -DBCMDRIVER -DBCMDONGLEHOST -DDHD THREAD -DBCMWPA2 -DUNRELEASEDCHIP -Dlinux -DDHD_SDALIGN=64 -DMAX_HDR_READ=64 -DDHD_ FIRSTREAD=64 -DDHD_GPL -DDHD_SCHED -DBDC -DTOE -DDHD_BCMEVENTS -DSHOW_EVENTS -DBCMS DIO -DDHD_GPL -DBCMLXSDMMC -DBCMPLATFORM_BUS -Wall -Wstrict-prototypes -Werror -DOO B_INTR_ONLY -DCUSTOMER_HW2 -DDHD_USE_STATIC_BUF -DMMC_SDIO_ABORT -DDHD_DEBUG_TRAP - DSOFTAP -DEMBEDDED_PLATFORM -DARP_OFFLOAD_SUPPORT -DPKT_FILTER_SUPPORT -DGET_CUSTOM _MAC_ENABLE -DSET_RANDOM_MAC_SOFTAP -DHW_OOB -Idrivers/net/wireless/bcm4329 -Idrive rs/net/wireless/bcm4329/include -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=K BUILD_STR(dhd_linux)" -D"KBUILD_MODNAME=KBUILD_STR(bcm4329)" -c -o drivers/net/wi reless/bcm4329/dhd_linux.o drivers/net/wireless/bcm4329/dhd_linux. ... [1]+ Donemake V=1 > build.log 2>&1 Compile CM-kernel with linaro. make -f scripts/Makefile.build obj=drivers/net/wireless/bcm4329 rm -f drivers/net/wireless/bcm4329/built-in.o; /usr/bin/arm-linux-gnueabi-ar rcs drivers/net/wireless/bcm4329/built-in.o /usr/bin/arm-linux-gnueabi-gcc -Wp,-MD,drivers/net/wireless/bcm4329/.dhd_linux.o.d -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.6.1/include -I/home/tknv/android/SuperSonic/kernels/CM-kernel/arch/arm/include -Iinclude -include include/generated/autoconf.h -D__KERNEL__ -mlittle-endian -Iarch/arm/mach-msm/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Wno-format-security -fno-delete-null-pointer-checks -Os -marm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-dwarf2-cfi-asm -fconserve-stack -DLINUX -DBCMDRIVER -DBCMDONGLEHOST -DDHDTHREAD -DBCMWPA2 -DUNRELEASEDCHIP -Dlinux -DDHD_SDALIGN=64 -DMAX_HDR_READ=64 -DDHD_FIRSTREAD=64 -DDHD_GPL -DDHD_SCHED -DBDC -DTOE -DDHD_BCMEVENTS -DSHOW_EVENTS -DBCMSDIO -DDHD_GPL -DBCMLXSDMMC -DBCMPLATFORM_BUS -Wall -Wstrict-prototypes -Werror -DOOB_INTR_ONLY -DCUSTOMER_HW2 -DDHD_USE_STATIC_BUF -DMMC_SDIO_ABORT -DDHD_DEBUG_TRAP -DSOFTAP -DEMBEDDED_PLATFORM -DARP_OFFLOAD_SUPPORT -DPKT_FILTER_SUPPORT -DGET_CUSTOM_MAC_ENABLE -DSET_RANDOM_MAC_SOFTAP -DHW_OOB -Idrivers/net/wireless/bcm4329 -Idrivers/net/wireless/bcm4329/include -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(dhd_linux)" -D"KBUILD_MODNAME=KBUILD_STR(bcm4329)" -c -o drivers/net/wireless/bcm4329/dhd_linux.o drivers/net/wireless/bcm4329/dhd_linux.c drivers/net/wireless/bcm4329/dhd_linux.c: In function ‘ dhd_rx_frame’: drivers/net/wireless/bcm4329/dhd_linux.c:1282:24: error: variable ‘save_pktbuf’ set but not used [-Werror=unused-but-set-variable] drivers/net/wireless/bcm4329/dhd_linux.c: In function ‘ dhd_os_wd_timer’
Re: Effect of alignment and peeling on vectorised loops
On 30 November 2011 22:28, Michael Hope wrote: >>> This run also showed the affect of loop unrolling. The loop seems to >>> be unrolled for loops of <= 64 words and drops off in performance past >>> around 8 words. When the unrolling finally drops out, performance >>> increases by 101 %. >> >> I see register spills starting from COUNT=36. > > Ah. Does the vectoriser cost model take register pressure into > account? How can I turn this on? No, but the vectorizer doesn't perform loop unrolling either. The unrolling here is done by complete_unroll pass after the vectorization, and AFAIK it doesn't take register pressure into account. On 1 December 2011 02:40, Michael Hope wrote: > I had a look in the backend and the vld1/vst1 %A operand adds the > alignment if known. It correctly adds [r1:64] if I feed in an array > of int64s. The code checks based on MEM_ALIGN and MEM_SIZE of the > operand: > align = MEM_ALIGN (x) >> 3; > memsize = INTVAL (MEM_SIZE (x)); > > Not sure why the backend generates a vldmia instead of a vld1 though. I don't see how the alignment info set by the vectorizer influences MEM_ALIGN. The vectorizer sets align and misalign fields of struct ptr_info_def. I see it used in expand_expr_real_1 for MEM_REF only to decide if there is a need in movmisalign (for unaligned accesses). MEM_ALIGN is determined in set_mem_attributes_minus_bitpos from DECL_ALIGN or TYPE_ALIGN. For the cases where the vectorizer forces alignment this should work, since we then set DECL_ALIGN (in vect_compute_data_ref_alignment). But peeling obviously doesn't change DECL_ALIGN, so I don't understand how we can create alignment hint in this case with the current code. Ira > > -- Michael > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Nov 27 - Dec 1
Hi, - Ran eon with gcc 4.7: there are much more loops similar to the one in lp#831094 that get vectorized (due to some data ref analysis improvement), so the impact of disabling peeling for such loops (i.e. loops with low loop bound) is even bigger than for 4.6, and vectorization improves the performance by 2.5%. I prefer to understand the peeling/alignment situation better and not just commit this patch (and I spent some time trying to do that). - Fixed PR 51301 - a bug in over-promotion pattern. Proposed for merge to gcc-linaro-4.6. - Merged the last SLP patch to gcc-linaro-4.6. Ira ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
