| Message ID | CAPK5YPbgHhyMvAC-o=5M1PSppj_d+G_Z0v5eDm_abaE9j9q34A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Mon, May 20, 2013 at 1:41 AM, Easwaran Raman <eraman@google.com> wrote: > PR tree-optimization/57322 > * (build_and_add_sum): If a BB is empty, set the UID of the statement > added to the BB to be 1. Maybe "gimple_set_uid (stmt, inc_gimple_stmt_max_uid (cfun));"? That would keep the UIDs unique except for the copied UIDs. Ciao! Steven
If you are suggesting using inc_gimple_stmt_max_uid(cfun) for all statements, that won't work because we want to use the UIDs to determine dominance within a BB. If your suggestion is to use that instead of 1 when BB == NULL, that would work (even though setting it to 1 is sufficient.) Thanks, Easwaran On Mon, May 20, 2013 at 4:43 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > On Mon, May 20, 2013 at 1:41 AM, Easwaran Raman <eraman@google.com> wrote: >> PR tree-optimization/57322 >> * (build_and_add_sum): If a BB is empty, set the UID of the statement >> added to the BB to be 1. > > Maybe "gimple_set_uid (stmt, inc_gimple_stmt_max_uid (cfun));"? That > would keep the UIDs unique except for the copied UIDs. > > Ciao! > Steven
On Mon, May 20, 2013 at 4:00 PM, Easwaran Raman wrote: > If your suggestion is to use that > instead of 1 when BB == NULL, that would work (even though setting it > to 1 is sufficient.) That's what I suggest, yes. I understand that 1 is sufficient for now, but you never know if/when someone will use these uids for something else within the pass and expect them to be more-or-less unique (only non-unique for consecutive insns). But I have no strong preference either way, 1 or max+1. Ciao! Steven
On Mon, May 20, 2013 at 4:04 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote: > On Mon, May 20, 2013 at 4:00 PM, Easwaran Raman wrote: >> If your suggestion is to use that >> instead of 1 when BB == NULL, that would work (even though setting it >> to 1 is sufficient.) > > That's what I suggest, yes. I understand that 1 is sufficient for now, > but you never know if/when someone will use these uids for something > else within the pass and expect them to be more-or-less unique (only > non-unique for consecutive insns). > > But I have no strong preference either way, 1 or max+1. It has to be 1 for correctness reason. The patch is ok with the testcase included. Thanks, Richard. > Ciao! > Steven
> 2013-05-19 Easwaran Raman <eraman@google.com> > > PR tree-optimization/57322 > * (build_and_add_sum): If a BB is empty, set the UID of the > statement added to the BB to be 1. Missing filename in the ChangeLog.
Index: gcc/tree-ssa-reassoc.c =================================================================== --- gcc/tree-ssa-reassoc.c (revision 199048) +++ gcc/tree-ssa-reassoc.c (working copy) @@ -1165,8 +1165,12 @@ build_and_add_sum (tree type, tree op1, tree op2, if ((!op1def || gimple_nop_p (op1def)) && (!op2def || gimple_nop_p (op2def))) { + gimple first_stmt; + unsigned uid; gsi = gsi_after_labels (single_succ (ENTRY_BLOCK_PTR)); - gimple_set_uid (sum, gimple_uid (gsi_stmt (gsi))); + first_stmt = gsi_stmt (gsi); + uid = first_stmt ? gimple_uid (first_stmt) : 1; + gimple_set_uid (sum, uid); gsi_insert_before (&gsi, sum, GSI_NEW_STMT); } else if ((!op1def || gimple_nop_p (op1def))
The UID of a newly generated statement in build_and_add_sum is set to that of an adjacent statement in the BB. This is a problem in one case where the BB is empty. This fix sets the UID to be 1 if the BB is empty. Bootstraps and no test regressions on x86_64 . OK for trunk? Thanks, Easwaran ----------- 2013-05-19 Easwaran Raman <eraman@google.com> PR tree-optimization/57322 * (build_and_add_sum): If a BB is empty, set the UID of the statement added to the BB to be 1.