This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Regimplification enhancements 3/3


Hi,

sorry for late reply, I've been on vacation and then preparing for
Cauldron.  Anyway...

On Mon, Jun 30, 2014 at 05:13:13PM +0200, Bernd Schmidt wrote:
> On 06/17/2014 04:54 PM, Martin Jambor wrote:
> >Weird... does the following (untested) patch help?
> >
> >diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
> >index 0afa197..747b1b6 100644
> >--- a/gcc/tree-sra.c
> >+++ b/gcc/tree-sra.c
> >@@ -3277,6 +3277,8 @@ sra_modify_assign (gimple *stmt, gimple_stmt_iterator *gsi)
> >
> >    if (modify_this_stmt
> >        || gimple_has_volatile_ops (*stmt)
> >+      || is_gimple_reg (lhs)
> >+      || is_gimple_reg (rhs)
> >        || contains_vce_or_bfcref_p (rhs)
> >        || contains_vce_or_bfcref_p (lhs)
> >        || stmt_ends_bb_p (*stmt))
> 
> Unfortunately not.
> 
> >It is just a quick thought though.  If it does not, could you post the
> >access trees dumped by -fdump-tree-esra-details or
> >-fdump-tree-sra-details (depending on whether this is early or late
> >SRA)?  Or is it simple to set it up locally?
> 
> Not really. It needs a whole patch tree for the ptx port. I'm
> attaching the last two dump files.
> 
> 
> Bernd
> 

> 
> ;; Function bar (bar, funcdef_no=0, decl_uid=1376, symbol_order=0)
> 
> 
> Pass statistics:
> ----------------
> 
> 
> Pass statistics:
> ----------------
> 
> bar (struct S xD.1375)
> {
>   struct S D.1385;
>   struct S aD.1378;
>   struct S D.1379;
>   struct S D.1381;
> 
> ;;   basic block 2, loop depth 0, count 0, freq 10000, maybe hot
> ;;    prev block 0, next block 1, flags: (NEW, REACHABLE)
> ;;    pred:       ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
>   # .MEM_2 = VDEF <.MEM_1(D)>
>   aD.1378 = xD.1375;
>   # .MEM_3 = VDEF <.MEM_2>
>   # USE = nonlocal 
>   # CLB = nonlocal 
>   _6 = fooD.1374 (aD.1378);
>   # .MEM_7 = VDEF <.MEM_3>
>   D.1379 = _6;

This seems to be the statement which has its RHS converted to to a
MEM_REF[&_6], am I right?  I wonder whether it is correct input
though, because it looks like it has mismatched types.  The LHS is
clearly an aggregate of type struct S while the RHS is an SSA name,
meaning it cannot be of an aggregate type.  Does this pass gimple
checking?  What creates that statement?

Thanks,

Martin


>   # .MEM_4 = VDEF <.MEM_7>
>   aD.1378 ={v} {CLOBBER};
>   # .MEM_5 = VDEF <.MEM_4>
>   D.1381 = D.1379;
>   # VUSE <.MEM_5>
>   return D.1381;
> ;;    succ:       EXIT [100.0%] 
> 
> }
> 
> 

> 
> ;; Function bar (bar, funcdef_no=0, decl_uid=1376, symbol_order=0)
> 
> 
> Pass statistics:
> ----------------
> 
> Candidate (1375): x
> Candidate (1385): D.1385
> Candidate (1378): a
> Candidate (1379): D.1379
> Candidate (1381): D.1381
> Will attempt to totally scalarize D.1379 (UID: 1379): 
> ! Disqualifying D.1385 - No or inhibitingly overlapping accesses.
> ! Disqualifying x - No scalar replacements to be created.
> ! Disqualifying a - No scalar replacements to be created.
> Created a replacement for D.1379 offset: 0, size: 32: SR$2
> 
> Access trees for D.1379 (UID: 1379): 
> access { base = (1379)'D.1379', offset = 0, size = 32, expr = D.1379.len, type = unsigned int, grp_read = 1, grp_write = 1, grp_assignment_read = 1, grp_assignment_write = 1, grp_scalar_read = 1, grp_scalar_write = 0, grp_total_scalarization = 1, grp_hint = 1, grp_covered = 1, grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_partial_lhs = 0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0, grp_maybe_modified = 0, grp_not_necessarilly_dereferenced = 0
> 
> ! Disqualifying D.1381 - No scalar replacements to be created.
> 
> Pass statistics:
> ----------------
> Scalarized aggregates: 1
> Modified expressions: 2
> Separate LHS and RHS handling: 2
> Scalar replacements created: 1
> 
> 
> Updating SSA:
> Registering new PHI nodes in block #0
> Registering new PHI nodes in block #2
> Updating SSA information for statement SR$2 = MEM[(struct S *)&_6];
> Updating SSA information for statement MEM[(struct S *)&D.1381] = SR$2;
> 
> DFA Statistics for bar
> 
> ---------------------------------------------------------
>                                 Number of        Memory
>                                 instances         used 
> ---------------------------------------------------------
> USE operands                              1          8b
> DEF operands                              2         16b
> VUSE operands                             6         48b
> VDEF operands                             4         32b
> PHI nodes                                 0          0b
> PHI arguments                             0          0b
> ---------------------------------------------------------
> Total memory used by DFA/SSA data                  104b
> ---------------------------------------------------------
> 
> 
> 
> Hash table statistics:
>     var_infos:   size 61, 1 elements, 0.000000 collision/search ratio
> 
> 
> Symbols to be put in SSA form
> { D.1387 }
> Incremental SSA update started at block: 0
> Number of blocks in CFG: 3
> Number of blocks to update: 2 ( 67%)
> Affected blocks: 0 2
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]