[PATCH GCC/pr56124] Don't prefer memory if the source of load operation has side effect

2013-03-25 Thread Bin Cheng
Hi,
As reported in PR56124, IRA causes redundant reload by preferring to put
pseudo which is target of loading in memory. Generally this is good but the
case in which the src of loading has side effect.
This patch fixes this issue by checking whether source of loading has side
effect.

I tested the patch on x86/thumb2. Is it OK? Thanks.

2013-03-25  Bin Cheng  

PR target/56124
* ira-costs.c (scan_one_insn): Check whether the source rtx of
loading has side effect.Index: gcc/ira-costs.c
===
--- gcc/ira-costs.c (revision 197029)
+++ gcc/ira-costs.c (working copy)
@@ -1293,10 +1293,13 @@ scan_one_insn (rtx insn)
  a memory requiring special instructions to load it, decreasing
  mem_cost might result in it being loaded using the specialized
  instruction into a register, then stored into stack and loaded
- again from the stack.  See PR52208.  */
+ again from the stack.  See PR52208.
+ 
+ Don't do this if SET_SRC (set) has side effect.  See PR56124.  */
   if (set != 0 && REG_P (SET_DEST (set)) && MEM_P (SET_SRC (set))
   && (note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != NULL_RTX
-  && ((MEM_P (XEXP (note, 0)))
+  && ((MEM_P (XEXP (note, 0))
+  && !side_effects_p (SET_SRC (set)))
  || (CONSTANT_P (XEXP (note, 0))
  && targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
XEXP (note, 0))


[PATCH GCC]Relax the probability condition in CE pass when optimizing for code size

2013-03-25 Thread Bin Cheng
Hi,
The CE pass has been adapted to work with the probability of then/else
branches. Now the transformation is done only when it's profitable.
Problem is the change affects both performance and size, causing size
regression in many cases (especially in C library like Newlib). 
So this patch relaxes the probability condition when we are optimizing for
size.

Below is an example from Newlib:

unsigned int strlen (const char *);
void * realloc (void * __r, unsigned int __size) ;
void * memcpy (void *, const void *, unsigned int);
int argz_add(char **argz , unsigned int *argz_len , const char *str)
{
  int len_to_add = 0;
  unsigned int last = *argz_len;

  if (str == ((void *)0))
return 0;

  len_to_add = strlen(str) + 1;
  *argz_len += len_to_add;

  if(!(*argz = (char *)realloc(*argz, *argz_len)))
return 12;

  memcpy(*argz + last, str, len_to_add);
  return 0;
}

The generated assembly for Os/cortex-m0 is like:

argz_add:
push{r0, r1, r2, r4, r5, r6, r7, lr}
mov r6, r0
mov r7, r1
mov r4, r2
ldr r5, [r1]
beq .L3
mov r0, r2
bl  strlen
add r0, r0, #1
add r1, r0, r5
str r0, [sp, #4]
str r1, [r7]
ldr r0, [r6]
bl  realloc
mov r3, #12
str r0, [r6]
cmp r0, #0
beq .L2
add r0, r0, r5
mov r1, r4
ldr r2, [sp, #4]
bl  memcpy
mov r3, #0
b   .L2
.L3:
mov r3, r2
.L2:
mov r0, r3

In which branch/mov instructions around .L3 can be CEed with this patch.

During the work I observed passes before combine might interfere with CE
pass, so this patch is enabled for ce2/ce3 after combination pass.

It is tested on x86/thumb2 for both normal and Os. Is it ok for trunk?


2013-03-25  Bin Cheng  

* ifcvt.c (ifcvt_after_combine): New static variable.
(cheap_bb_rtx_cost_p): Set scale to REG_BR_PROB_BASE when optimizing
for size.
(rest_of_handle_if_conversion, rest_of_handle_if_after_combine):
Clear/set the variable ifcvt_after_combine.Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c (revision 197029)
+++ gcc/ifcvt.c (working copy)
@@ -67,6 +67,9 @@
 
 #define NULL_BLOCK ((basic_block) NULL)
 
+/* TRUE if after combine pass.  */
+static bool ifcvt_after_combine;
+
 /* # of IF-THEN or IF-THEN-ELSE blocks we looked at  */
 static int num_possible_if_blocks;
 
@@ -144,8 +147,14 @@ cheap_bb_rtx_cost_p (const_basic_block bb, int sca
   /* Our branch probability/scaling factors are just estimates and don't
  account for cases where we can get speculation for free and other
  secondary benefits.  So we fudge the scale factor to make speculating
- appear a little more profitable.  */
+ appear a little more profitable when optimizing for performance.  */
   scale += REG_BR_PROB_BASE / 8;
+
+  /* Set the scale to REG_BR_PROB_BASE to be more agressive when
+ optimizing for size and after combine pass.  */
+  if (!optimize_function_for_speed_p (cfun) && ifcvt_after_combine)
+scale = REG_BR_PROB_BASE;
+
   max_cost *= scale;
 
   while (1)
@@ -4445,6 +4454,7 @@ gate_handle_if_conversion (void)
 static unsigned int
 rest_of_handle_if_conversion (void)
 {
+  ifcvt_after_combine = false;
   if (flag_if_conversion)
 {
   if (dump_file)
@@ -4494,6 +4504,7 @@ gate_handle_if_after_combine (void)
 static unsigned int
 rest_of_handle_if_after_combine (void)
 {
+  ifcvt_after_combine = true;
   if_convert ();
   return 0;
 }


RE: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

2012-10-31 Thread Bin Cheng


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
> Behalf Of Jakub Jelinek
> Sent: Tuesday, October 30, 2012 1:57 AM
> To: gcc@gcc.gnu.org
> Cc: gcc-patc...@gcc.gnu.org
> Subject: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
> 
> Status
> ==
> 
> I'd like to close the stage 1 phase of GCC 4.8 development on Monday,
November
> 5th.  If you have still patches for new features you'd like to see in GCC
4.8,
> please post them for review soon.  Patches posted before the freeze, but
> reviewed shortly after the freeze, may still go in, further changes should
be
> just bugfixes and documentation fixes.
> 
> 
> Quality Data
> 
> 
> Priority  #   Change from Last Report
> ---   ---
> P1   23   + 23
> P2   77   +  8
> P3   85   + 84
> ---   ---
> Total   185   +115
> 
> 
> Previous Report
> ===
> 
> http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html
> 
> The next report will be sent by me again, announcing end of stage 1.

Hi,
I am working on register pressure directed hoist pass and have committed the
main patch in trunk. Here I still have two patches in this area improving
it. I will send these two patches recently and hope it can be included in
4.8 if OK.

Thanks.