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
> message 11100 (18 Apr 2006))
operate on original 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
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:
>> On 21 April 2016 at 03:41, lh_mouse wrote:
>>> See t
; if(ptrs[0] == ptrs[1]){
> abort();
> }
> }
>
> int main(){
> foo();
> }
> [/code]
>
> --
> Best regards,
> lh_mouse
> 2016-04-21
>
> -----
> 发件人：Jonathan Wakely
> 发送日期
s involved,
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
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
> Matt
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
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 programme
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@
> -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 wrote:
>
> -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
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
ta
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
situ
case, 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 wrote:
&g
ne? I
am working on up-to-date GCC 4.8.
Thanks,
Bingfeng Mei
haran Sandanagobalane
Cc: Bingfeng Mei; Andrew Haley; GCC Development
Subject: Re: builtin function - novops
On Mon, Mar 17, 2014 at 1:59 AM, Hariharan Sandanagobalane
wrote:
> Hello,
> This question is similar to one raised by bingfeng here
>
> http://gcc.gnu.org/ml/gcc/2010-04/msg00241.html
>
&
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 &
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 itera
[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?
>
te: mark 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;
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:
> > > I
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
new operator. 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
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
dr_b);
return refs_may_alias_p (addr_a, addr_b);
This issue can be reproduced on trunk x86-64 gcc.
Cheers,
Bingfeng Mei
)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2014-01-28 Bingfeng Mei
+
+ * 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
Revert
Index: g
n 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 M
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))
code1, code2, multi_step_cvt,
interm_types))
return true;
Thanks,
Bingfeng Mei
n
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 &
rget now.
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 w
[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 +0000, Bingfeng Mei wrote:
> Well, in your modified example
@gmail.com]
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 wrote:
> Hi,
> I am doing some investigation on loops can be vectorize
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
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
, 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
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
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
> Sen
To: Richard Guenther
> 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 wro
chard.guent...@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 wrote:
> > Hi,
> > I experienced a code generation bug with
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
11 11:13
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: SLP vectorizer on non-loop?
>
>
>
> gcc-ow...@gcc.gnu.org wrote on 01/11/2011 12:41:32 PM:
>
> > Hello,
> > I have one example with two very similar loops. cunrolli pass
> > unrolls one loop compl
work. I wonder 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;i<4;i++)
temp_hist_buffer[i]=p_hist_buff[i]
t; Cc: Bingfeng Mei; gcc@gcc.gnu.org
> Subject: Re: Why doesn't GCC generate conditional move for COND_EXPR?
>
> On Mon, Oct 24, 2011 at 7:00 AM, Richard Guenther
> wrote:
> > On Mon, Oct 24, 2011 at 2:55 PM, Bingfeng Mei
> wrote:
> >> Hello,
> >> I
don't turned -ftree-vectorize on. This
is on our private port.
Thanks,
Bingfeng Mei
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: Portin
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
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
4.7
~/work/install-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
asts.
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,
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
>
(mem)))
return 0;
else
return 1;
}
Is this correct?
Thanks,
Bingfeng Mei
> -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 wrote:
&
t; so 3 "a++" can be
optimized?
Thanks,
Bingfeng Mei
int a;
int P[100];
void foo (int * restrict p)
{
P[0] = *p;
a++;
P[1] = *p;
a++;
P[2] = *p;
a++;
}
~/work/install-arm/bin/arm-elf-gcc tst.c -O2 -S -std=c99
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_
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
utations 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?
&
understand correctly or miss something here?
Thanks,
Bingfeng Mei
e case, we should have
a compiler hook to choose between them. BTW, I mainly work
on 4.5, maybe 4.6 has changed.
Thanks,
Bingfeng Mei
> -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 caus
> -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
> instructi
gt; From: Ian Lance Taylor [mailto:i...@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" writes:
>
> > from gen_reload func
(reg:SI 4 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
>
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
0:37
> To: Bingfeng 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"
> To: Revital
13 December 2010 07:59
> 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; how
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
> -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, Bin
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
distin
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 da
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 recl
tation fault.
(gdb) p vector->u.fld[0].rt_rtvec
$15 = (rtvec) 0x2a95905028
(gdb) p *(vector->u.fld[0].rt_rtvec)
$16 = {num_elem = -1515870811, elem = {0xa5a5a5a5a5a5a5a5}}
I really have no clue on how to debug such issue.
Any suggestion is greatly appreciated.
Thanks
Bingfeng Mei
: Re: Why is -fstrict-aliasing excluded from function "optimize"
> attribute?
>
> On 11/03/2010 08:44 PM, Richard Guenther wrote:
> > On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley wrote:
> >> On 11/03/2010 04:49 PM, Bingfeng Mei wrote:
> >>> Hello,
> &
h internal manual and gcc 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
e-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 29 September 2010 13:33
> 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 wrote:
> > Hello,
> > I hav
like this. Maybe we should exclude
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
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
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,
which
(reg/v:V2SI 86 [ c ])
(reg:V2SI 90))) 511 {fp_predv2si} (nil))
(insn 12 11 16 2 tst.c:16 (set (reg:V2SI 87 [ ])
(reg/v:V2SI 85 [ c ])) 190 {fp_movv2si} (nil))
(insn 16 12 19 2 tst.c:18 (set (reg/i:V2SI 8 r8)
(reg/v:V2SI 85 [ c ])) 190 {fp_movv2si} (nil))
Cheers,
Bin
> Sent: 08 September 2010 11:26
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Function-specific optimization flags and inlining
>
> On Wed, Sep 8, 2010 at 12:07 PM, Bingfeng Mei wrote:
> > Hello,
> > I found that currently if a function with specific opti
[mailto:richard.guent...@gmail.com]
> Sent: 08 September 2010 11:26
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Function-specific optimization flags and inlining
>
> On Wed, Sep 8, 2010 at 12:07 PM, Bingfeng Mei wrote:
> > Hello,
> > I found that currently if a fu
e any function with
specific optimization flags or have an extra option to choose that. What do
you think?
Cheers,
Bingfeng Mei
Hello,
I came across an issue regarding named section and nobits. In
the following example, I expected the c is placed is placed
in a section named .smemdata and nobits is set for the section
since "c" is initialized to zeros.
int a = 0;
int b = 2000 * 512;
static int c[(200 * 512)] __attribute
Bosscher [mailto:stevenb@gmail.com]
> Sent: 04 August 2010 16:26
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; Richard Guenther
> Subject: Re: Shouldn't alias_sets_conflict_p be replaced with
> rtx_refs_may_alias_p?
>
> On Wed, Aug 4, 2010 at 2:02 PM, Bingfeng Mei wrote:
&g
Hi,
alias_sets_conflict_p are still used in various places to determine
whether two memory accesses are aliased. It is based on unique set
number, which seems not correct with recent changes on alias
oracle. For example, in ddg.c cross-iteration memory dependence
is drawn by calling insn_alias_sets
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 03 August 2010 17:22
> To: Bingfeng Mei
> Cc: Alexander Monakov; gcc@gcc.gnu.org
> Subject: Re: Restrict qualifier still not working?
>
> On Tue, Aug 3, 2010 at 6:11
Thanks,
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 03 August 2010 10:33
> To: Bingfeng Mei
> Cc: Alexander Monakov; gcc@gcc.gnu.org
> Subject: Re: Restrict qualifier still not working?
>
> On Tue, Aug 3
> -Original Message-
> From: Alexander Monakov [mailto:amona...@ispras.ru]
> Sent: 02 August 2010 17:48
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; Richard Guenther
> Subject: Re: Restrict qualifier still not working?
>
>
>
> On Mon, 2 Aug 2010, Bingfeng Mei
Hi,
I ran a small test to see how the trunk/4.5 works
with the rewritten restrict qualified pointer code. But it doesn't
seem to work on both x86-64 and our port.
tst.c:
void foo (int * restrict a, int * restrict b,
int * restrict c, int * restrict d)
{
*c = *a + 1;
*d = *b + 1;
}
Hello,
I am interested to attend GCC summit this year, but it doesn't seem
to happen, does it?
Cheers,
Bingfeng
Hello,
I started to look at VTA recently and check whether our port passes
the -fcompare-debug test. Our port contains some extra passes for
our VLIW target.
What I have trouble is with our modulo scheduling pass (based on
IMS algorithm). I noticed that debug_insns are built into DDG,
and has
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: 01 July 2010 16:27
> To: Richard Guenther
> Cc: Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Convert cross reference table to resolution file for LTO
>
> Hi,
>
> On Thu
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 01 July 2010 16:13
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Convert cross reference table to resolution file for LTO
>
> On Thu, Jul 1, 2010
Hi,
I did some experiments to convert cross-reference table
to resolution files. Patches are attached and still crude.
The initial idea is to have as little as possible change
in GNU LD. It turns out that cross reference table doesn't
always print out definition at the first line. So
some chan
Hi,
I just updated from last week's version to 160732. It seems broken due to the
latest changes in c-family directory.
./../trunk/gcc/c-family/c-cppbuiltin.c: In function 'void
builtin_define_with_hex_fp_value(const char*, tree_node*, int, const char*,
const char*, const char*)':
../../trunk/gc
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Ian Lance Taylor
> Sent: 14 June 2010 05:43
> To: David Brown
> Cc: gcc@gcc.gnu.org
> Subject: Re: Issue with LTO/-fwhole-program
>
> David Brown writes:
>
> > After doing a bit more readin
> -Original Message-
> From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com]
> Sent: 11 June 2010 14:14
> To: Bingfeng Mei
> Cc: Dave Korn; Richard Guenther; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Issue with LTO/-fwhole-program
>
> On 11 June 2010 15
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 11 June 2010 14:08
> To: Bingfeng Mei
> Cc: Dave Korn; Manuel López-Ibáñez; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Issue with LTO/-fwhole-program
>
> On Fri, Jun 11, 2
rn.cyg...@gmail.com]
> Sent: 11 June 2010 14:21
> To: Richard Guenther
> Cc: Manuel López-Ibáñez; Bingfeng Mei; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Issue with LTO/-fwhole-program
>
> On 11/06/2010 13:59, Richard Guenther wrote:
>
> > Well, we can't. We specific
Hi,
I am still puzzled by the effect of LTO/-fwhole-program.
For the following simple tests:
a.c:
#include
int v;
extern void bar();
int main()
{
v = 5;
bar();
printf("v = %d\n", v);
return 0;
}
b.c:
int v;
void bar()
{
v = 4;
}
If I just compile plainly, the output is:
v = 4
I
> -Original Message-
> From: Cary Coutant [mailto:ccout...@google.com]
> Sent: 09 June 2010 18:43
> To: Richard Guenther
> Cc: Bingfeng Mei; Jan Hubicka; gcc@gcc.gnu.org
> Subject: Re: externally_visible and resoultion file
>
> >> Yes, this is also wha
1 - 100 of 236 matches
Mail list logo
