insn 882 : cc - compare (r684, 0)
jump_insn 883 : if (cc != 0) goto insn 46
insn 49: r291 - r684
..
insn 46
cc contains the result of subtracting 0 from r684; control flow goes to
insn_49 only if (cc == 0), which implies (r684 == 0).
Then at insn_49 we have
On 09/29/11 17:36, Jeff Law wrote:
On 09/29/11 09:26, Bernd Schmidt wrote:
ISTR cse.c has some support for this.
cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Interesting. Are the two approaches subtly different
or do they apply precisely the same predication?
I have been working on your patch but I didn't manage to get it
working yet. Unfortunately our current stable GCC version if 4.3.4 and
our 4.4.x still has some issues.
I tried backporting your patch to GCC 4.3.4 but it introduced several
regressions. It's my guess this is due to my incorrect
I will be looking at the patch Rahul posted and will try to see if I
can improve on it.
See attached patch (again) that Paulo is referring to. Sending to GCC
failed due to email client issues.
I have another patch for http://gcc.gnu.org/ml/gcc/2010-08/msg00413.html
Which I will send out
;
}
int
main (int argc, char **argv)
{
int i;
for (i = 0; i sizeof(seq)/sizeof(seq[0]); i++)
result = test_it (1, i);
return 0;
}
Cheers,
Rahul
-Original Message-
From: Rahul Kharche
Sent: 22 April 2010 11:24
To: Edmar Wienskoski
Cc: Steven Bosscher; Jan Hubicka; gcc@gcc.gnu.org
Thanks Edmar! I will try and work your patch into our GCC 4.4.1
port and get some results.
Cheers,
Rahul
Hi Steven,
There is a transformation implemented in GCC's
value profiling to put the most-frequently taken case-label of a
switch-expr at the top of the switch
Could you point me to the bit of code that does this?
I'm exploring the idea of implementing source hints much like
__builtin_expect
?
-Original Message-
From: Jan Hubicka [mailto:hubi...@ucw.cz]
Sent: 14 April 2010 00:44
To: Rahul Kharche
Cc: gcc@gcc.gnu.org; sdkteam-gnu
Subject: Re: branch probabilities on multiway branches
Hi All,
The following bit of code in predict.c implies branch probabilities
are strictly evenly
What is the problem you're trying to solve?
Generally speaking I was looking for a better logic based on estimated
branch probability to decide between using binary search tree and jump
table implementation of a switch case.
One interesting test case is where the gross structure of a function
is
The other case I'm working on is to selectively apply tailcall
optimization when optimizing for size. Clearly tail call optimiztion
is desirable along frequently executed edges. Otherwise we found
tailcall optimization generates a sicall_epilogue for each tailcall
which has a significant impact on
Hi All,
The following bit of code in predict.c implies branch probabilities
are strictly evenly distributed for multiway branches at present. The
comment suggests it is possible to generate better estimates for more
generic cases, apart from being involved. Could anyone point me to
the reference
Hi Jeff,
Many thanks for the pointers. I will make the changes and attach the
patch to the bugzilla soon.
Cheers,
Rahul
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: 09 February 2010 00:45
To: Rahul Kharche
Cc: gcc@gcc.gnu.org; sdkteam-gnu
Subject: Re: Failure
Hi All,
On our private port of GCC 4.4.1 we fail to combine successive SHIFT
operations like in the following case
#include stdlib.h
#include stdio.h
void f1 ()
{
unsigned short t1;
unsigned short t2;
t1 = rand();
t2 = rand();
t1 = 1; t2 = 1;
t1 = 1; t2 = 1;
t1 = 1; t2 = 1;
t1
October 2009 14:50
To: Rahul Kharche
Cc: rgue...@gcc.gnu.org; gcc@gcc.gnu.org; sdkteam-gnu
Subject: Re: RFC PRE-ing REFERENCE expressions
On Fri, Oct 30, 2009 at 3:22 PM, Rahul Kharche ra...@icerasemi.com wrote:
Hi Richi,
Following up your suggestion on PR41488, I am continuing to test
Hi Richi,
Following up your suggestion on PR41488, I am continuing to test with
loop header copy before FRE in GCC 4.4.1. One regression I am trying
to tackle is from the test case below.
typedef struct {
int degree;
int c[(256)];
} swbcht_Polynomial;
typedef struct {
int m;
int n;
The following causes missed loop optimizations in O2 from creating
unnecessary loop induction variables. Or, is a case of IV opts not
able to coalesce copies of induction variables. A previous post related
to this was made in PR41026 which had a type promoted loop index
variable
copied. I believe
Hi,
I am trialing this patch on a private GCC port that I'm working on.
The patch works well with several test cases we have. However, fails
on the following
int
main ()
{
const int arr[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
int i;
for (i = 0; i 10; i++)
{
printf(arr[%d] :
4.4.1, GCC 4.4 branch. Will I need dependent changes from the 4.5
branch?
Many Thanks,
Rahul
-Original Message-
From: Bernd Schmidt [mailto:bernds_...@t-online.de]
Sent: 22 May 2009 16:56
To: Rahul Kharche
Cc: gcc@gcc.gnu.org; sdkteam-all
Subject: Re: [4.5] Find more autoinc addressing
Hi,
Its fixed for me. I was missing get_ref_tag () in copy_ref_info () when
I patched against 4.5.
Thanks again,
Rahul
-Original Message-
From: Bernd Schmidt [mailto:bernds_...@t-online.de]
Sent: 22 May 2009 16:56
To: Rahul Kharche
Cc: gcc@gcc.gnu.org; sdkteam-all
Subject: Re: [4.5
- If I patch in this code, actually I get the same results I did
before where the constants are propagated. It seems that in 4.3.2,
every part of the compiler is trying to do that.
There are at least two forward propagation passes, one before and
another after GCSE. I haven't tried to tackle
Hi Jean,
Do you have a link to that patch? So that I can see if it applies for
me ?
See patch below. I put in some comments to try and explain what I have
attempted to do.
The hash SET generation, to track potential candidates in replacing a
register USE, needed some tweaking. This function
I am looking at a related problem in GCSE, GCC 4.3 whereby constants
are propagated to their use irrespective of the final instruction cost
of generating them (machine cycles or instruction count).
Global constant propagation effectively voids common expressions that
form large constants,
22 matches
Mail list logo
