On Thu, Jun 13, 2013 at 1:43 AM, Richard Biener
wrote:
> On Sat, Jun 8, 2013 at 2:26 AM, Xinliang David Li wrote:
>> On Fri, Jun 7, 2013 at 6:47 AM, Richard Biener
>> wrote:
>>> On Fri, Jun 7, 2013 at 3:30 PM, Xinliang David Li
>>> wrote:
On Fri, Jun 7, 2013 at 2:05 AM, Richard Biener
>>>
On Sat, Jun 8, 2013 at 2:26 AM, Xinliang David Li wrote:
> On Fri, Jun 7, 2013 at 6:47 AM, Richard Biener
> wrote:
>> On Fri, Jun 7, 2013 at 3:30 PM, Xinliang David Li wrote:
>>> On Fri, Jun 7, 2013 at 2:05 AM, Richard Biener
>>> wrote:
On Thu, Jun 6, 2013 at 5:10 PM, Dehao Chen wrote:
>>
Hi,
On Thu, Jun 06, 2013 at 08:10:13AM -0700, Dehao Chen wrote:
> Hi, Martin,
>
> Yes, your patch can fix my case. Thanks a lot for the fix.
good. However, as usual when I'm trying to do things too quickly, I
made a stupid mistaker and testing has revealed I picked exactly the
wrong branch in t
On Fri, Jun 7, 2013 at 6:47 AM, Richard Biener
wrote:
> On Fri, Jun 7, 2013 at 3:30 PM, Xinliang David Li wrote:
>> On Fri, Jun 7, 2013 at 2:05 AM, Richard Biener
>> wrote:
>>> On Thu, Jun 6, 2013 at 5:10 PM, Dehao Chen wrote:
Hi, Martin,
Yes, your patch can fix my case. Thanks a
On Fri, Jun 7, 2013 at 6:47 AM, Richard Biener
wrote:
> On Fri, Jun 7, 2013 at 3:30 PM, Xinliang David Li wrote:
>> On Fri, Jun 7, 2013 at 2:05 AM, Richard Biener
>> wrote:
>>> On Thu, Jun 6, 2013 at 5:10 PM, Dehao Chen wrote:
Hi, Martin,
Yes, your patch can fix my case. Thanks a
On Fri, Jun 7, 2013 at 3:30 PM, Xinliang David Li wrote:
> On Fri, Jun 7, 2013 at 2:05 AM, Richard Biener
> wrote:
>> On Thu, Jun 6, 2013 at 5:10 PM, Dehao Chen wrote:
>>> Hi, Martin,
>>>
>>> Yes, your patch can fix my case. Thanks a lot for the fix.
>>>
>>> With the fix, value profiling will st
On Fri, Jun 7, 2013 at 2:05 AM, Richard Biener
wrote:
> On Thu, Jun 6, 2013 at 5:10 PM, Dehao Chen wrote:
>> Hi, Martin,
>>
>> Yes, your patch can fix my case. Thanks a lot for the fix.
>>
>> With the fix, value profiling will still promote the wrong indirect
>> call target. Though it will not be
On Thu, Jun 6, 2013 at 5:10 PM, Dehao Chen wrote:
> Hi, Martin,
>
> Yes, your patch can fix my case. Thanks a lot for the fix.
>
> With the fix, value profiling will still promote the wrong indirect
> call target. Though it will not be inlining, but it results in an
> additional check. How about i
This one should be submitted and discussed in trunk.
thanks,
David
On Thu, Jun 6, 2013 at 9:39 PM, Dehao Chen wrote:
> I've prepared a patch check for args for indirect call value profiling.
>
> Testing on-going. Is it ok for trunk if testing is good?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
> 20
I've prepared a patch check for args for indirect call value profiling.
Testing on-going. Is it ok for trunk if testing is good?
Thanks,
Dehao
gcc/ChangeLog:
2013-06-06 Dehao Chen
* tree-flow.h (gimple_check_call_matching_types): Add new argument.
* gimple-low.c (gimple_check
On Thu, Jun 6, 2013 at 7:11 AM, Martin Jambor wrote:
> Hi,
>
> On Tue, Jun 04, 2013 at 05:19:02PM -0700, Dehao Chen wrote:
>> attached is a testcase that would cause problem when source has changed:
>>
>> $ g++ test.cc -O2 -fprofile-generate -DOLD
>> $ ./a.out
>> $ g++ test.cc -O2 -fprofile-use
>>
gimple_check_call_matching_types is called by check_ic_target. Instead
of moving the check out of this guard function, may be enhancing the
interface to allow it to guard with different strictness?
David
On Thu, Jun 6, 2013 at 8:10 AM, Dehao Chen wrote:
> Hi, Martin,
>
> Yes, your patch can fix
Hi, Martin,
Yes, your patch can fix my case. Thanks a lot for the fix.
With the fix, value profiling will still promote the wrong indirect
call target. Though it will not be inlining, but it results in an
additional check. How about in check_ic_target, after calling
gimple_check_call_matching_typ
On Thu, Jun 6, 2013 at 4:11 PM, Martin Jambor wrote:
> Hi,
>
> On Tue, Jun 04, 2013 at 05:19:02PM -0700, Dehao Chen wrote:
>> attached is a testcase that would cause problem when source has changed:
>>
>> $ g++ test.cc -O2 -fprofile-generate -DOLD
>> $ ./a.out
>> $ g++ test.cc -O2 -fprofile-use
>>
Hi,
On Tue, Jun 04, 2013 at 05:19:02PM -0700, Dehao Chen wrote:
> attached is a testcase that would cause problem when source has changed:
>
> $ g++ test.cc -O2 -fprofile-generate -DOLD
> $ ./a.out
> $ g++ test.cc -O2 -fprofile-use
> test.cc:34:1: internal compiler error: in operator[], at vec.h:
On Wed, Jun 5, 2013 at 6:11 PM, Xinliang David Li wrote:
> Right, except that in the context of FDO/autoFDO, where this happens
> the most (note in FDO case, it can happen with fresh profile too for
> multi-threaded programs), it is not that important to handle -- the
> mismatch path will never be
Right, except that in the context of FDO/autoFDO, where this happens
the most (note in FDO case, it can happen with fresh profile too for
multi-threaded programs), it is not that important to handle -- the
mismatch path will never be executed, so why bother to inline and
bloat the code for it?
if
On Wed, Jun 5, 2013 at 2:19 AM, Dehao Chen wrote:
> attached is a testcase that would cause problem when source has changed:
>
> $ g++ test.cc -O2 -fprofile-generate -DOLD
> $ ./a.out
> $ g++ test.cc -O2 -fprofile-use
> test.cc:34:1: internal compiler error: in operator[], at vec.h:815
> }
> ^
>
attached is a testcase that would cause problem when source has changed:
$ g++ test.cc -O2 -fprofile-generate -DOLD
$ ./a.out
$ g++ test.cc -O2 -fprofile-use
test.cc:34:1: internal compiler error: in operator[], at vec.h:815
}
^
0x512740 vec::operator[](unsigned int)
../../gcc/vec.h:815
0x512740
Richard's question is that inlining should deal with extra arguments
just fine -- those paths (the insane profile case) won't be executed
anyway. Do you have a case showing otherwise (i.e., the mismatch
upsets the compiler?)
David
On Tue, Jun 4, 2013 at 8:07 AM, Dehao Chen wrote:
> On Tue, Jun
On Tue, Jun 4, 2013 at 3:56 AM, Richard Biener
wrote:
>
> On Tue, Jun 4, 2013 at 2:55 AM, Dehao Chen wrote:
> > Hi,
> >
> > This patch was committed to google branch. But I think it is of
> > general interest. So is it ok for trunk?
> >
> > Thanks,
> > Dehao
> >
> > gcc/ChangeLog:
> >
> > 2013-06
On Tue, Jun 4, 2013 at 2:55 AM, Dehao Chen wrote:
> Hi,
>
> This patch was committed to google branch. But I think it is of
> general interest. So is it ok for trunk?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
>
> 2013-06-03 Dehao Chen
>
> *gimple-low.c (gimple_check_call_args): Restrict the call_a
Hi,
This patch was committed to google branch. But I think it is of
general interest. So is it ok for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2013-06-03 Dehao Chen
*gimple-low.c (gimple_check_call_args): Restrict the call_arg check to
contain same number of args.
Index: gcc/gimple-low.c
==
Those cases you mentioned may lead to problems in inlining, indirect
target promotion transformations etc too, so it is better to use the
new guard against them.
David
On Fri, May 31, 2013 at 1:15 AM, Duncan Sands wrote:
> Hi Dehao,
>
>
> On 31/05/13 00:47, Dehao Chen wrote:
>>
>> This patch mak
Hi Dehao,
On 31/05/13 00:47, Dehao Chen wrote:
This patch makes more strict check of call args to make sure the
number of args match.
Bootstrapped and passed regression tests.
did you thoroughly test Fortran? The Fortran front-end has long had an
unfortunate tendency to eg declare a function
Yes, patch updated:
Testing on-going.
Dehao
Index: gimple-low.c
===
--- gimple-low.c (revision 199414)
+++ gimple-low.c (working copy)
@@ -254,6 +254,8 @@
&& !fold_convertible_p (DECL_ARG_TYPE (p), arg)))
return fals
On Thu, May 30, 2013 at 3:47 PM, Dehao Chen wrote:
> This patch makes more strict check of call args to make sure the
> number of args match.
>
> Bootstrapped and passed regression tests.
>
> OK for google branches?
>
> Thanks,
> Dehao
>
> Index: gcc/gimple-low.c
>
This patch makes more strict check of call args to make sure the
number of args match.
Bootstrapped and passed regression tests.
OK for google branches?
Thanks,
Dehao
Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c (revision 19941
28 matches
Mail list logo
