On Thu, Jul 24, 2014 at 2:38 PM, Martin Jambor <mjam...@suse.cz> wrote:
> 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?
Yeah, looks clearly invalid. MEM_REF[&_6] is not valid even if
the types were correct (taking the address of an SSA name).
Richard.
> 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
>>
>>
>
