Re: LLVM disagrees with GCC on bitfield handling

HI, Joseph, Thanks for detailed explanation. Cheers, Bingfeng On Thu, Oct 26, 2017 at 5:11 PM, Joseph Myers wrote: > There is a line of C90 DRs and associated textual history (compare the > relevant text in C90 and C99, or see my comparison of it in WG14 reflector >

LLVM disagrees with GCC on bitfield handling

inal data types. I am confused which approach conforms to standard, or this is just a grey area not well defined by standard. Any suggestion is greatly appreciated. Cheers, Bingfeng Mei

Re: Re: Why does gcc generate const local array on stack?

Richard, thanks for explanation. I found an option -fmerge-all-constants, which can help me work around for now. BIngfeng On Thu, Apr 21, 2016 at 11:15 AM, Richard Biener wrote: > On Thu, Apr 21, 2016 at 11:39 AM, Jonathan Wakely > wrote: >>

Re: Re: Why does gcc generate const local array on stack?

> } > if(ptrs[0] == ptrs[1]){ > abort(); > } > } > > int main(){ > foo(); > } > [/code] > > -- > Best regards, > lh_mouse > 2016-04-21 > > --------- > 发件人：Jonathan Wake

Why does gcc generate const local array on stack?

, GCC would have to maintain the array on stack and hence the initialization. But here the code is very simple. I don't understand the logic of generated code, or maybe missing optimization opportunity? Thanks, Bingfeng Mei

RE: Vector modes and the corresponding width integer mode

I don't think it is required. For example, PowerPC port supports V8SImode, but I don't see OImode. Just sometimes it could come handy to have the equal size scalar mode. Cheers, Bingfeng -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of

RE: [PATCH] PR61868

Thanks, Jeff. Checked in. Bingfeng -Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: 31 July 2014 04:43 To: Bingfeng Mei; Richard Biener Cc: Andi Kleen; gcc-patches@gcc.gnu.org Subject: Re: [PATCH] PR61868 On 07/30/14 09:20, Bingfeng Mei wrote: Yes, that fix

RE: [PATCH] PR61868

? Bingfeng -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 30 July 2014 08:47 To: Bingfeng Mei; Andi Kleen Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] PR61868 On Tue, Jul 29, 2014 at 3:01 PM, Bingfeng Mei b...@broadcom.com wrote: Hi, Please

RE: [PATCH] PR61868

It did take a lot of time, but passed the LTO bootstrap. Bingfeng -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 30 July 2014 10:43 To: Bingfeng Mei Cc: Andi Kleen; gcc-patches@gcc.gnu.org Subject: Re: [PATCH] PR61868 On Wed, Jul 30, 2014 at 10

RE: [PATCH] PR61868

; flag_random_seed = val; + init_random_seed (); return old; } Bingfeng -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 30 July 2014 10:43 To: Bingfeng Mei Cc: Andi Kleen; gcc-patches@gcc.gnu.org Subject: Re: [PATCH] PR61868 On Wed, Jul 30, 2014 at 10:52 AM

RE: [PATCH] PR61868

Yes, that fix is better. Here are updated patches. LTO-bootstrapped and tested. OK? Bingfeng Index: ChangeLog === --- ChangeLog (revision 213152) +++ ChangeLog (working copy) @@ -1,3 +1,10 @@ +2014-07-29 Bingfeng Mei b

[PATCH] PR61868

, Bingfeng Mei === --- ChangeLog (revision 213152) +++ ChangeLog (working copy) @@ -1,3 +1,9 @@ +2014-07-29 Bingfeng Mei b...@broadcom.com + + PR lto/61868 + * toplev.c (init_random_seed): Generate random seed when

ivdep pragma not used in ddg.c?

Hi, I noticed recent GCC adds ivdep pragma support. We have our own implementation for ivdep for a couple of years now. As GCC implementation is much cleaner and we want to migrate to it. Ivdep is consumed in two places in our implementation, one is tree-vect-data-refs.c used by vectorizer, the

RE: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM

Thanks for nice benchmarks. Vladimir. Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling on GCC? It doesn't seem increasing code size help performance (164.gzip 197.parser) Is there comparisons for O2? I guess that is more useful for typical mobile/embedded

RE: regs_used estimation in IVOPTS seriously flawed

-Original Message- From: Bin.Cheng [mailto:amker.ch...@gmail.com] Sent: 20 June 2014 06:25 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: regs_used estimation in IVOPTS seriously flawed On Tue, Jun 17, 2014 at 10:59 PM, Bingfeng Mei b...@broadcom.com wrote: Hi, I am

RE: regs_used estimation in IVOPTS seriously flawed

Sorry, typo in previous mail. I also tried counting all SSA names and divide it by a factor. It does NOT seem to work so well -Original Message- From: Bin.Cheng [mailto:amker.ch...@gmail.com] Sent: 20 June 2014 10:19 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: regs_used

RE: regs_used estimation in IVOPTS seriously flawed

-Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 18 June 2014 12:36 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: regs_used estimation in IVOPTS seriously flawed On Tue, Jun 17, 2014 at 4:59 PM, Bingfeng Mei b...@broadcom.com wrote: Hi, I

RE: Register Pressure guided Unroll and Jam in GCC !!

That is true. Early estimation of register pressure should be improved. Right now I am looking at an example IVOPTS produces too many induction variables and causes a lot of register spilling. Though ivopts pass called estimate_reg_pressure_cost function, results are not even close to real

regs_used estimation in IVOPTS seriously flawed

Hi, I am looking at a performance regression in our code. A big loop produces and uses a lot of temporary variables inside the loop body. The problem appears that IVOPTS pass creates even more induction variables (from original 2 to 27). It causes a lot of register spilling later and performance

[PATCH] default_add_stmt_cost should call target specific builitin_vectorization_cost.

TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST is defined, it will use that cost. Otherwise, it will fall back to default_builtin_vectorization_cost. Bootstrapped and tested. OK for trunk? Thanks, Bingfeng Mei Index: gcc/ChangeLog

RE: [PATCH] default_add_stmt_cost should call target specific builitin_vectorization_cost.

Thanks. Committed. Bingfeng -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 06 June 2014 10:40 To: Bingfeng Mei Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] default_add_stmt_cost should call target specific builitin_vectorization_cost. On Fri, Jun

RE: Why is this not optimized?

, but should be better in general. Cheers, Bingfeng -Original Message- From: Bin.Cheng [mailto:amker.ch...@gmail.com] Sent: 15 May 2014 06:59 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Why is this not optimized? On Wed, May 14, 2014 at 9:14 PM, Bingfeng Mei b...@broadcom.com wrote

Why is this not optimized?

-to-date GCC 4.8. Thanks, Bingfeng Mei

RE: builtin function - novops

Sandanagobalane Cc: Bingfeng Mei; Andrew Haley; GCC Development Subject: Re: builtin function - novops On Mon, Mar 17, 2014 at 1:59 AM, Hariharan Sandanagobalane hariharan@gmail.com wrote: Hello, This question is similar to one raised by bingfeng here http://gcc.gnu.org/ml/gcc/2010-04/msg00241.html

RE: Merge epilog loop loop version due to alias/alignment in vectorization?

Thanks, it seems that Cong's idea is exactly what I meant. Is there a patch I can try? Bingfeng -Original Message- From: Xinliang David Li [mailto:davi...@google.com] Sent: 04 February 2014 18:57 To: Bingfeng Mei Cc: gcc@gcc.gnu.org; Cong Hou Subject: Re: Merge epilog loop loop

Merge epilog loop loop version due to alias/alignment in vectorization?

Hi, One of biggest issues we have with GCC vectorization is bloated code size. For example, vectorized version is 2.5 times of non-vectorized one for the following simple code. One reason is that GCC often creates one loop copy because of aliasing/alignment and one epilog loop because of loop

RE: No TBAA before ptr_derefs_may_alias_p?

If it is just for C++ placement new, why don't implement it as a lang_hook. Now other languages such as C have to be made conservative and produce worse code. Bingfeng -Original Message- From: Richard Biener [mailto:rguent...@suse.de] Sent: 31 January 2014 19:44 To: Bingfeng Mei; gcc

RE: No TBAA before ptr_derefs_may_alias_p?

Weimer Cc: Jakub Jelinek; Bingfeng Mei; gcc@gcc.gnu.org Subject: Re: No TBAA before ptr_derefs_may_alias_p? On Mon, 3 Feb 2014, Florian Weimer wrote: On 02/03/2014 10:59 AM, Jakub Jelinek wrote: On Mon, Feb 03, 2014 at 09:51:01AM +, Bingfeng Mei wrote: If it is just for C++ placement new

RE: No TBAA before ptr_derefs_may_alias_p?

for run-time aliasing test between _10-real and *_7 tst3.c:12: note: versioning for alias required: can't determine dependence Bingfeng -Original Message- From: Richard Biener [mailto:rguent...@suse.de] Sent: 03 February 2014 10:35 To: Jakub Jelinek Cc: Bingfeng Mei; gcc@gcc.gnu.org

RE: No TBAA before ptr_derefs_may_alias_p?

[mailto:rguent...@suse.de] Sent: 03 February 2014 13:16 To: Bingfeng Mei Cc: Florian Weimer; Jakub Jelinek; gcc@gcc.gnu.org Subject: RE: No TBAA before ptr_derefs_may_alias_p? On Mon, 3 Feb 2014, Bingfeng Mei wrote: For the following code, why can load be moved before store instruction? TBAA still

No TBAA before ptr_derefs_may_alias_p?

); This issue can be reproduced on trunk x86-64 gcc. Cheers, Bingfeng Mei

RE: No TBAA before ptr_derefs_may_alias_p?

Thanks, Richard, I will prepare a patch with test as well as filing a bug. Bingfeng -Original Message- From: Richard Biener [mailto:rguent...@suse.de] Sent: 31 January 2014 15:24 To: Bingfeng Mei; gcc@gcc.gnu.org Subject: Re: No TBAA before ptr_derefs_may_alias_p? On 1/31/14 4:02 PM

RE: No TBAA before ptr_derefs_may_alias_p?

. But this example is pretty clear and has nothing to do with C++ and new statement. Isn't it too conservative to disable TBAA for anti- output- dependency here? Bingfeng -Original Message- From: Richard Biener [mailto:rguent...@suse.de] Sent: 31 January 2014 15:24 To: Bingfeng Mei; gcc

RE: VEC_WIDEN_MULT_(LO|HI)_EXPR vs. VEC_WIDEN_MULT_(EVEN|ODD)_EXPR in vectorization.

in the output vector (operand 0). So I thought that implementing both can help vectorizer to optimize more loops. Maybe we should improve documents. Bingfeng -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 28 January 2014 11:02 To: Bingfeng Mei Cc: gcc

RE: VEC_WIDEN_MULT_(LO|HI)_EXPR vs. VEC_WIDEN_MULT_(EVEN|ODD)_EXPR in vectorization.

/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2014-01-28 Bingfeng Mei b...@broadcom.com + + * doc/md.texi: Mention that a target shouldn't implement + vec_widen_(s|u)mul_even/odd pair if it is less efficient + than hi/lo pair. + 2014-01-28 Richard Biener rguent...@suse.de

Suspected bugs in ptr_difference_const split_address_to_core_and_offset

Hi, I experienced an issue in our port, which I suspected due to bugs in ptr_difference_const split_address_to_core_and_offset. Basically, ptr_difference_const, called by ivopts pass, tries to evaluate whether e1 e2 differ by a const. In this example, e1 is (addr_expr (mem_ref (ssa_name1, 8))

VEC_WIDEN_MULT_(LO|HI)_EXPR vs. VEC_WIDEN_MULT_(EVEN|ODD)_EXPR in vectorization.

, interm_types)) return true; Thanks, Bingfeng Mei

[PING] [PATCH] fixed pr59651 new test case

Updated: the patch passes aarch64 tests. Added missing ChangeLog entry for testsuite. OK to commit? Bingfeng -Original Message- From: Bingfeng Mei Sent: 02 January 2014 15:02 To: gcc-patches@gcc.gnu.org Cc: 'tbela...@arm.com' Subject: [PATCH] fixed pr59651 new test case Hi

[COMMITTED] [PATCH] fixed pr59651 new test case

Jakub, thanks. Committed with suggested changes. Bingfeng -Original Message- From: Jakub Jelinek [mailto:ja...@redhat.com] Sent: 03 January 2014 14:26 To: Bingfeng Mei Cc: gcc-patches@gcc.gnu.org; tbela...@arm.com Subject: Re: [PING] [PATCH] fixed pr59651 new test case On Fri, Jan 03

[PATCH] fixed pr59651 new test case

Hi, This patch fixes pr59651. The original regression for pr52943 only appears on AArch64 target. I constructed a similar test that also exposes bug on x86-64. The problem is that calculation of address range in alias versioning for loops with negative step is wrong during vectorization. For

[PATCH] Fix PR59569

Hi, Jakub, Thanks for suggestion. Please find attached patch. GCC is bootstrapped and passes testsuite on x86-64. Let me know if it is OK to commit. (Sorry if you received this mail twice as I forgot to set to text format). Thanks, Bingfeng Mei patch_pr59569 Description: patch_pr59569

RE: [PATCH] Fix PR59569

All the 3 tests are tested and the first two are included in my patch. Didn't include the third one as it is not reduced. Bingfeng -Original Message- From: H.J. Lu [mailto:hjl.to...@gmail.com] Sent: 23 December 2013 14:28 To: Bingfeng Mei Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek (ja

[COMMITTED]RE: [PATCH] Fix PR59569

Committed. I will prepare some new tests as you suggested. Thanks, Bingfeng -Original Message- From: Jakub Jelinek [mailto:ja...@redhat.com] Sent: 23 December 2013 14:53 To: Bingfeng Mei Cc: gcc-patches@gcc.gnu.org; H.J. Lu (hjl.to...@gmail.com) Subject: Re: [PATCH] Fix PR59569 On Mon

[PATCH] [followup to PR59569] new vect tests for store with negative step

Hi, Here are two vectorization tests for store with negative step. This is follow-up to PR59569 fix, which contains two tests for ICE. These tests are for vectorization tests and executable. OK to commit? Thanks, Bingfeng patch_vect_tests Description: patch_vect_tests

[COMMITTED] RE: [PATCH] [followup to PR59569] new vect tests for store with negative step

Thanks. Committed with suggested change. Merry Christmas! Bingfeng -Original Message- From: Jakub Jelinek [mailto:ja...@redhat.com] Sent: 23 December 2013 16:48 To: Bingfeng Mei Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] [followup to PR59569] new vect tests for store

[PING] RE: [PATCH] Vectorization for store with negative step

OK to commit? Thanks, Bingfeng -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bingfeng Mei Sent: 18 December 2013 16:25 To: Jakub Jelinek Cc: Richard Biener; gcc-patches@gcc.gnu.org Subject: RE: [PATCH] Vectorization for store

RE: Vectorization for store with negative step

:26 To: Bingfeng Mei Cc: gcc-patches@gcc.gnu.org Subject: Re: Vectorization for store with negative step On Mon, Dec 16, 2013 at 5:54 PM, Bingfeng Mei b...@broadcom.com wrote: Hi, I was looking at some loops that can be vectorized by LLVM, but not GCC. One type of loop is with store of negative

[PATCH] Vectorization for store with negative step

Hi, I created PR59544 and here is the patch. OK to commit? Thanks, Bingfeng 2013-12-18 Bingfeng Mei b...@broadcom.com PR tree-optimization/59544 * tree-vect-stmts.c (perm_mask_for_reverse): Move before vectorizable_store. (vectorizable_store): Handle negative step. 2013

RE: [PATCH] Vectorization for store with negative step

Hi, Jakub, Sorry for all the formatting issues. Haven't submit a patch for a while :-). Please find the updated patch. Thanks, Bingfeng -Original Message- From: Jakub Jelinek [mailto:ja...@redhat.com] Sent: 18 December 2013 13:38 To: Bingfeng Mei Cc: Richard Biener; gcc-patches

Vectorization for store with negative step

: # %for.end ret Any comment? Bingfeng Mei Broadcom UK patch Description: patch

RE: Jump threading in tree dom pass prevents if-conversion following vectorization

] Sent: 21 November 2013 21:26 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Jump threading in tree dom pass prevents if-conversion following vectorization On Thu, Nov 21, 2013 at 7:11 AM, Bingfeng Mei b...@broadcom.com wrote: Hi, I am doing some investigation on loops can be vectorized

RE: Jump threading in tree dom pass prevents if-conversion following vectorization

[mailto:james.greenha...@arm.com] Sent: 22 November 2013 11:50 To: Bingfeng Mei Cc: Andrew Pinski; gcc@gcc.gnu.org Subject: Re: Jump threading in tree dom pass prevents if-conversion following vectorization On Fri, Nov 22, 2013 at 11:03:22AM +, Bingfeng Mei wrote: Well, in your modified example

RE: Jump threading in tree dom pass prevents if-conversion following vectorization

. Bingfeng -Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: 22 November 2013 16:58 To: Bingfeng Mei; Andrew Pinski Cc: gcc@gcc.gnu.org Subject: Re: Jump threading in tree dom pass prevents if-conversion following vectorization On 11/22/13 04:03, Bingfeng Mei wrote: Well

RE: Jump threading in tree dom pass prevents if-conversion following vectorization

be fixed without disabling jump threading. Bingfeng -Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: 22 November 2013 17:17 To: Bingfeng Mei; Andrew Pinski; Richard Biener Cc: gcc@gcc.gnu.org Subject: Re: Jump threading in tree dom pass prevents if-conversion following

Vectorization: Loop peeling with misaligned support.

, the size is 80bytes vs. 352 bytes without patch (-O2 -ftree-vectorize gcc 4.8.3 20131114) int A[100]; int B[100]; void foo2() {   int i;   for (i = 0; i 100; ++i)     A[i] = B[i] + 100; } What is the best way to tell vectorizer not to do peeling in such situation? Thanks, Bingfeng Mei

RE: Vectorization: Loop peeling with misaligned support.

is faster but bigger, what should be right balance? How to do with cases that are a bit faster and a lot bigger? Thanks, Bingfeng -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 15 November 2013 14:02 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re

RE: Vectorization: Loop peeling with misaligned support.

to guarantee to generate loop peeling. Bingfeng -Original Message- From: Xinliang David Li [mailto:davi...@google.com] Sent: 15 November 2013 17:30 To: Bingfeng Mei Cc: Richard Biener; gcc@gcc.gnu.org Subject: Re: Vectorization: Loop peeling with misaligned support. The right longer

RE: Vectorizer question

If both X Y are vectors, GCC will report error (at least on our port based on 4.5) as invalid operands to ==. Not sure if it is extended for 4.7. Bingfeng -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Iyer, Balaji V Sent: 17 May 2012 00:01

RE: Bug in Tree to RTL expansion?

Cc: Bingfeng Mei; gcc@gcc.gnu.org Subject: Re: Bug in Tree to RTL expansion? Hi, On Thu, 8 Dec 2011, Richard Guenther wrote: What I am not sure is whether the coalescing algorithm or the expanding procedure is wrong here. The forwarding of _218 is wrong. TER shouldn't have marked

RE: Bug in Tree to RTL expansion?

OK, don't bother. I think I understand TER and my issue now. It is from a misfix of widening multiplication, which I found there is a new pass doing this from 4.6. I am going to back port that to my target. Thanks, Bingfeng -Original Message- From: Bingfeng Mei Sent: 09 December 2011

Bug in Tree to RTL expansion?

, it should be also OK. Which one should I I look at? Or is this a known issue and fixed in 4.6/4.7? Thanks, Bingfeng Mei

RE: Bug in Tree to RTL expansion?

...@gmail.com] Sent: 08 December 2011 12:10 To: Bingfeng Mei Cc: gcc@gcc.gnu.org; Michael Matz Subject: Re: Bug in Tree to RTL expansion? On Thu, Dec 8, 2011 at 12:34 PM, Bingfeng Mei b...@broadcom.com wrote: Hi, I experienced a code generation bug with 4.5 (yes, our port is still stuck

SLP vectorizer on non-loop?

how easy to make SLP works for non-loop. Thanks, Bingfeng Mei Broadcom UK void foo (int *__restrict__ temp_hist_buffer, int * __restrict__ p_hist_buff, int *__restrict__ p_input) { int i; for(i=0;i4;i++) temp_hist_buffer[i]=p_hist_buff[i]; for(i=0;i4;i

RE: SLP vectorizer on non-loop?

Ira, Thank you very much for quick answer. I will check 4.7 x86-64 to see difference from our port. Is there significant change between 4.5 4.7 regarding SLP? Cheers, Bingfeng -Original Message- From: Ira Rosen [mailto:i...@il.ibm.com] Sent: 01 November 2011 11:13 To: Bingfeng Mei

RE: Why doesn't GCC generate conditional move for COND_EXPR?

with tree vectorization or some other passes). Maybe it is worth to make it default at -O2 (for those processors support conditional move)? Cheers, Bingfeng -Original Message- From: Andrew Pinski [mailto:pins...@gmail.com] Sent: 24 October 2011 17:20 To: Richard Guenther Cc: Bingfeng Mei

Why doesn't GCC generate conditional move for COND_EXPR?

don't turned -ftree-vectorize on. This is on our private port. Thanks, Bingfeng Mei

RE: Porting 64-bit target on 32-bit host

I believe that 64-bit target on 32-bit host is not supported by GCC. You need a lot of hackings to do so. Check this thread. http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00908.html Bingfeng Mei -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf

RE: Porting 64-bit target on 32-bit host

Well, I just switched to 64-bit host and everything is fine. Bingfeng -Original Message- From: harder...@gmail.com [mailto:harder...@gmail.com] On Behalf Of Huang Ping Sent: 10 October 2011 16:55 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Porting 64-bit target on 32-bit

Not conform to c90?

-x86/bin/gcc test.c -O2 -std=c90 size = 0 I noticed the following statement in GCC document. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero. Does it mean GCC just does not conform to c90 in this respect? Thanks, Bingfeng Mei

RE: Not conform to c90?

Thank you very much. I misunderstood the document. Bingfeng -Original Message- From: Jonathan Wakely [mailto:jwakely@gmail.com] Sent: 04 October 2011 12:48 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Not conform to c90? On 4 October 2011 12:09, Bingfeng Mei wrote

[PATCH] correct TARGET_ADDR_SPACE_SUBSET_P documentation.

? Cheers, Bingfeng Mei 2011-09-26 Bingfeng Mei b...@broad.com * doc/tm.texi: Correct documentation for TARGET_ADDR_SPACE_SUBSET_P. Index: doc/tm.texi === --- doc/tm.texi (revision 178972) +++ doc/tm.texi (working copy) @@ -10256,7

RE: [PATCH] correct TARGET_ADDR_SPACE_SUBSET_P documentation.

Richard, Here are updated patches. tm.texi.in doesn't need any change as the description of the hook is correct, just the order of parameters needs change. Thanks, Bingfeng 2011-09-26 Bingfeng Mei b...@broad.com * doc/tm.texi: Correct documentation for TARGET_ADDR_SPACE_SUBSET_P

Wrong documentation of TARGET_ADDR_SPACE_SUBSET_P

. In spu m32c ports: m32c_addr_space_subset_p (addr_space_t subset, addr_space_t superset) spu_addr_space_subset_p (addr_space_t subset, addr_space_t superset) I believe the document is wrong. The first argument is subset and the second one is superset. Should I submit a patch? Cheers, Bingfeng Mei

RE: [PATCH] derive alias information from named address spaces.

Hello, Here is the updated patch. OK now? Thanks, Bingfeng 2011-09-22 Bingfeng Mei b...@broadcom.com * alias.c (mems_in_disjoint_address_spaces_p) New function. (nonoverlapping_memrefs_p): Use mems_in_disjoint_address_sapces_p to derive alias information

[PATCH] derive alias information from named address spaces.

Hello, The following patch is to derive more alias information from named address spaces using existing target hook. It was discussed in http://gcc.gnu.org/ml/gcc/2011-09/msg00180.html Bootstrapped and tested on x86-64. OK for trunk? Thanks, Bingfeng 2011-09-20 Bingfeng Mei b

RE: Derive more alias information from named address space

Thanks. I will prepare a patch. Bingfeng -Original Message- From: Ulrich Weigand [mailto:uweig...@de.ibm.com] Sent: 19 September 2011 12:56 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Derive more alias information from named address space Bingfeng Mei wrote: Therefore

Derive more alias information from named address space

; else return 1; } Is this correct? Thanks, Bingfeng Mei

Is this correct behaviour?

Hi, I compile the following code with arm gcc 4.6 (x86 is the similar with one of 4.7 snapshot). I noticed a is written to memory three times instead of being added by 3 and written at the end. Doesn't restrict guarantee a won't be aliased to p so 3 a++ can be optimized? Thanks, Bingfeng Mei

RE: Is this correct behaviour?

-Original Message- From: Richard Guenther [mailto:richard.guent...@gmail.com] Sent: 06 September 2011 16:42 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Is this correct behaviour? On Tue, Sep 6, 2011 at 5:30 PM, Bingfeng Mei b...@broadcom.com wrote: Hi, I compile

Why does GCC convert short operation to short unsigned?

int) a; b.1 = (short unsigned int) b; D.3350 = a.0 - b.1; D.3347 = (short int) D.3350; return D.3347; } Is this for some C standard conformance, or optimization purpose? This doesn't happen with int type. Thanks, Bingfeng Mei

RE: Vector permutation only deals with # of vector elements same as mask?

on load and store. Cheers, Bingfeng -Original Message- From: Ira Rosen [mailto:i...@il.ibm.com] Sent: 10 February 2011 17:22 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Vector permutation only deals with # of vector elements same as mask? Hi, Bingfeng Mei b

Vector permutation only deals with # of vector elements same as mask?

understand correctly or miss something here? Thanks, Bingfeng Mei

Why doesn't vetorizer skips loop peeling/versioning for target supports hardware misaligned access?

should have a compiler hook to choose between them. BTW, I mainly work on 4.5, maybe 4.6 has changed. Thanks, Bingfeng Mei

RE: BImode is treated as normal byte-wide mode and causes bug.

-Original Message- From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: 22 December 2010 14:33 To: Claudiu Zissulescu Cc: Bingfeng Mei; gcc@gcc.gnu.org Subject: Re: BImode is treated as normal byte-wide mode and causes bug. On 12/20/2010 12:43

RE: Is eliminate_regs_in_insn allowed to generate invalid instruction?

-Original Message- From: Ulrich Weigand [mailto:uweig...@de.ibm.com] Sent: 17 December 2010 18:48 To: Bingfeng Mei Cc: i...@google.com; gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org Subject: Re: Is eliminate_regs_in_insn allowed to generate invalid instruction? Bingfeng Mei wrote

RE: Is eliminate_regs_in_insn allowed to generate invalid instruction?

r4) (plus:SI (mult:SI (reg:SI 9 r9) (const_int 8 [0x8])) (reg:SI 4 r4))) -1 (nil)) and load from [r4] subsequently. Bingfeng -Original Message- From: Ian Lance Taylor [mailto:i...@google.com] Sent: 17 December 2010 01:26 To: Bingfeng Mei Cc: gcc

RE: Is eliminate_regs_in_insn allowed to generate invalid instruction?

...@google.com] Sent: 17 December 2010 15:10 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Is eliminate_regs_in_insn allowed to generate invalid instruction? Bingfeng Mei b...@broadcom.com writes: from gen_reload function. /* Otherwise, just write (set OUT IN) and hope for the best

Is eliminate_regs_in_insn allowed to generate invalid instruction?

this is an wrong transformation and causes the following ICE. Is it allowed that Eliminate_regs_in_insn to generate such illegal instruction? Cheers, Bingfeng Mei

RE: A question about using restrict

To: gcc@gcc.gnu.org Cc: Bingfeng Mei Subject: A question about using restrict Hello, I have the loop below and I want to pass to gcc that src1 and src2 never alias with dst; so I used the restrict keyword as below; however I still see that there are dependence edges between dst and src1

RE: A question about using restrict

Mei Cc: gcc@gcc.gnu.org Subject: RE: A question about using restrict Hello Bingfeng, Thanks for your reply! I would be very interested to try your patch. Revital From: Bingfeng Mei b...@broadcom.com To: Revital1 Eres/Haifa/i...@ibmil, gcc@gcc.gnu.org gcc

BImode is treated as normal byte-wide mode and causes bug.

Hi, I am investigating a bug in our target port. It is due to following optimization done by combine pass. (zero_extend:SI (reg:BI 120)) is transformed to (and:SI (subreg:SI (reg:BI 120) 0) (const_int 255 [0xff])) in expand_compound_operation (combine.c), where BImode is just treated as

Revisit of pr38212 regarding restrict definition

Hi, I am working on how to improve restrict. I noticed that my changes lead to failure of pr38212. After looking at its code, I think the test may not be valid according to c99 standard. C99 standard 6.7.3.1: EXAMPLE 4 The rule limiting assignments between restricted pointers does not

RE: Revisit of pr38212 regarding restrict definition

-Original Message- From: Richard Guenther [mailto:richard.guent...@gmail.com] Sent: 30 November 2010 13:53 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Revisit of pr38212 regarding restrict definition On Tue, Nov 30, 2010 at 2:07 PM, Bingfeng Mei b...@broadcom.com wrote

Should restrictness be preserved over function linling and casting?

Hello, I have been struggling with GCC's restrict implementation. One question is: should restrictness be preserved over function inlining? For example, in the following code: static int store_int (int *a, int data) { *a = data; } void foo (int * __restrict a, int *__restrict b) { int

RE: How to debug when some rtx are wrongly reclaimed by garbage collector?

I am not aware of that. Thank you very much. Cheers, Bingfeng -Original Message- From: Andreas Schwab [mailto:sch...@redhat.com] Sent: 12 November 2010 11:24 To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: How to debug when some rtx are wrongly reclaimed by garbage collector

Why is -fstrict-aliasing excluded from function optimize attribute?

manual. It seems not to be documented. I wonder whether there is a good reason for this? If yes, at least we should document it. BTW, the code certainly works in 4.4. Regards, Bingfeng Mei

Worse code generated by PRE

such case in the first place? I read the relevant text in Advanced Compiler Design Implementation, the example used is linear CFG and it doesn't mention how to handle loop case. Any suggestion is greatly appreciated. Thanks, Bingfeng Mei

RE: Worse code generated by PRE

To: Bingfeng Mei Cc: gcc@gcc.gnu.org Subject: Re: Worse code generated by PRE On Wed, Sep 29, 2010 at 2:16 PM, Bingfeng Mei b...@broadcom.com wrote: Hello, I have been examining a significant performance regression between 4.5 and 4.4 in our port. I found that Partial Redundancy

RE: Question about alias check in ddg.c

The old insns_may_alias_p is based checking alias set number. But since 4.5, the new alias oracle doesn't rely the alias set number. may_alias_p() is a new function based on alias oracle. Essentially, it is same as true_dependence function but excluding offset and TBAA based disambiguation,

RE: Question about alias check in ddg.c

It doesn't fail on my target, which is based on 4.5 and has backported this patch. I will have a look at PowerPC. Bingfeng -Original Message- From: Revital1 Eres [mailto:e...@il.ibm.com] Sent: 15 September 2010 13:51 To: Bingfeng Mei Subject: RE: Question about alias check in ddg.c

  1   2   3   >