Re: Question about macro _GLIBCXX_RES_LIMITS in libstdc++ testsuite

2015-05-16 Thread Hans-Peter Nilsson
On Thu, 23 Apr 2015, Bin.Cheng wrote:
> Hi,
> In libstdc++ testsuite, I noticed that macro _GLIBCXX_RES_LIMITS is
> checked/set by GLIBCXX_CHECK_SETRLIMIT, which is further guarded by
> GLIBCXX_IS_NATIVE as below:
>
> AC_DEFUN([GLIBCXX_CONFIGURE_TESTSUITE], [
>   if $GLIBCXX_IS_NATIVE ; then
> # Do checks for resource limit functions.
> GLIBCXX_CHECK_SETRLIMIT
>
> # Look for setenv, so that extended locale tests can be performed.
> GLIBCXX_CHECK_STDLIB_DECL_AND_LINKAGE_3(setenv)
>   fi
>
> For cross toolchain like arm-linux, _GLIBCXX_RES_LIMITS isn't set.  As
> a result, function __gnu_test::set_file_limit is actually nullified
> and causing case 27_io/fpos/14775.cc failed.
>
> My question is why we want to guard the check with GLIBCXX_IS_NATIVE?
> Could we check it directly, if it's not supported, it's going to fail
> and undef the macro anyway?
>
>
> Thanks,
> bin
>

Good question.  I'm CC:ing the libstdc++ list, maybe that'll
bring an answer before another 1.5 months.

brgds, H-P


[RFC] Design and Implementation for Path Splitting for Loop with Conditional IF-THEN-ELSE

2015-05-16 Thread Ajit Kumar Agarwal
I have Designed and  implemented with the following design for the path 
splitting of the loops with conditional IF-THEN-ELSE.
The implementation has gone through the bootstrap for Microblaze target along 
DEJA GNU regressions tests and
running the MIBench/EEMBC benchmarks. There is no regression seen in Deja GNU 
tests and Deja C++ tests results are
better with the path splitting changes(lesser failures). The Mibench/EEMBC 
benchmarks are run and no performance degradation is
seen and the performance improvement in telcom_gsm( Mibench benchmarks) of 
9.15% and rgbcmy01_lite(EEMBC
benchmarks) the performance improvement of 9.4% is observed.

Proposal on the below were made earlier on path splitting and the reference is 
attached.

https://gcc.gnu.org/ml/gcc/2015-03/msg00057.html

The above gains are achieved because of the constant propagation on conditional 
which become much easier with the
Path splitting changes and benefitted with other optimization on tree 
representation along with better register allocation.
Because of the better granularity.

I will make the SPEC run and Bootstrap on i386 target Before that I would like 
to receive your feedbacks and comments 
 on design and implementation done. I will send the actual patch with SPEC run 
and bootstrap on i386 target after
 I receive the feedback on the design  and the implementation mentioned in this 
mail.

Design changes.

1. The dominators of the block with conditional IF statements say BB1 are found 
and the join node of the IF-THEN-ELSE
inside the loops is found on the blocks dominated by the BB1 and are not 
successor of BB1 are the join node.

2. The Join node is same as the source of the loops latch basic blocks.

3. If the above conditional in (1) and (2) are found the Join node  same as the 
source of the Loop latch node is
moved into predecessors and the Join node ( Source of the Loop latch node) is 
made empty statement block with only
the phi nodes.

4. In the process of moving the Join node into its predecessors the result of 
the phi node in the Join node propagated
with the corresponding phi arguments  based on which predecessor it came from 
in the Join blocks and move into its predecessors.

5. The Dominator INFO is updated after performing the steps of (1) (2) (3) and 
(4).

6. The Join which is same as the source of the Loop latch node is made empty 
with only the phi node in the Join node.

7. The implementation is done in Jump threading phase of the machine 
independent optimization on tree based
representation. The path splitting is called after the Jump threading 
optimization is performed.
The following files are modifed.

a) tree-vrp.c
b) tree-ssa-threadedge.c
c) tree-cfg.c
d) tree-ssa-threadedge.h
e) tree-cfg.h
f) cfghooks.c

The diff is attached along with this mail and pasted below.

Please share your thoughts and feedbacks on the above optimization and the 
design and the coding and implementation
done for the given above design.

diff --git a/gcc/cfghooks.c b/gcc/cfghooks.c
index 9faa339..559ca96 100644
--- a/gcc/cfghooks.c
+++ b/gcc/cfghooks.c
@@ -581,7 +581,7 @@ delete_basic_block (basic_block bb)
 
   /* If we remove the header or the latch of a loop, mark the loop for
 removal.  */
-  if (loop->latch == bb
+  if (loop && loop->latch == bb
  || loop->header == bb)
mark_loop_for_removal (loop);
 
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index aed5254..b25e409 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -1838,6 +1838,64 @@ replace_uses_by (tree name, tree val)
 }
 }
 
+void
+gimple_threaded_merge_blocks (basic_block a, basic_block b)
+{
+  gimple_stmt_iterator last, gsi, psi;
+
+  if (dump_file)
+fprintf (dump_file, "Merging blocks %d and %d\n", a->index, b->index);
+
+   /* Remove labels from B and set gimple_bb to A for other statements.  */
+  for (gsi = gsi_start_bb (b); !gsi_end_p (gsi);)
+ {
+   gimple stmt = gsi_stmt (gsi);
+   if (glabel *label_stmt = dyn_cast  (stmt))
+ {
+   tree label = gimple_label_label (label_stmt);
+   int lp_nr;
+
+   gsi_remove (&gsi, false);
+
+   if (FORCED_LABEL (label))
+ {
+   gimple_stmt_iterator dest_gsi = gsi_start_bb (a);
+   gsi_insert_before (&dest_gsi, stmt, GSI_NEW_STMT);
+ }
+ /* Other user labels keep around in a form of a debug stmt.  */
+ else if (!DECL_ARTIFICIAL (label) && MAY_HAVE_DEBUG_STMTS)
+ {
+   gimple dbg = gimple_build_debug_bind (label,
+ integer_zero_node,
+ stmt);
+
+   gimple_debug_bind_reset_value (dbg);
+
+   gsi_insert_before (&gsi, dbg, GSI_SAME_STMT);
+
+ }
+   lp_nr = EH_LANDING_PAD_NR (label);
+   if (lp_nr)
+ {
+   

Re: [RFC] Design and Implementation for Path Splitting for Loop with Conditional IF-THEN-ELSE

2015-05-16 Thread shmeel gutl

On 16-May-15 03:49 PM, Ajit Kumar Agarwal wrote:

if (loop && loop->latch == bb
  || loop->header == bb)
Please add parenthesis to the various occurrences of this code fragment. 
Better if the precedence is explicit.