Re: [PR81165] discount killed stmts when sizing blocks for threading

[Jeff Law <law at redhat dot com>]

On 12/11/2017 10:08 PM, Alexandre Oliva wrote:
> 
>> I wonder if for the handling of a larger threading path it wouldn't be useful to
>> keep ssa_remaining_uses live and populated across processing of the threaded
>> conditionals?  OTOH it would probably require to track uses on the path vs.
>> not on the path.
> 
> Possibly.  Not sure.  I wondered about that myself.
So I finally found the other BZ in this space that I was looking for.
36550.

In 36550 we're getting a false positive warning at -Os because we
restrict jump threading to cases where the copied block has no real
statements other than the control statement at the end (which we're
going to eliminate).

As it turns out in the 36550 case the key block has real statements, but
they're all going to be dead after threading.  So naturally Alex's code
is of interest here.

I wonder if we could attach the result of Alex's analysis bits to the
thread path, then query it later.  That would allow us to solve 36550
without re-analyzing the path.  See class tree-ssa-threadupdate.h's
definition of jump_thread_edge -- that's where I want to hang the result
of the analysis.

Alex want to take a looksie and see if you can attach the result to the
path, then query it in tree-ssa-threadupdate.c at this point:

 /* If optimizing for size, only thread through block if we don't have
     to duplicate it or it's an otherwise empty redirection block.  */
  if (optimize_function_for_size_p (cfun))
    {
      EXECUTE_IF_SET_IN_BITMAP (tmp, 0, i, bi)
        {
          bb = BASIC_BLOCK_FOR_FN (cfun, i);
          if (EDGE_COUNT (bb->preds) > 1
              && !redirection_block_p (bb))
            {
              FOR_EACH_EDGE (e, ei, bb->preds)
                {
                  if (e->aux)
                    {
                      vec<jump_thread_edge *> *path = THREAD_PATH (e);
                      delete_jump_thread_path (path);
                      e->aux = NULL;
                    }
                }
            }
          else
            bitmap_set_bit (threaded_blocks, i);


There may be other BZs of a similar nature -- there's certainly others
were we get spurious -Wuninitialized warnings with -Os where threading
got throttled.  But I haven't verified if all the statements in the
copied block were dead on those other BZs.




> 
> 
>>    PARAM_MAX_JUMP_THREAD_DUPLICATION_STMTS specifies the maximum number
>>    of statements and PHI nodes allowed in a block which is going to
>>    be duplicated for thread jumping purposes.
> 
>> should be adjusted though?
> 
> I guess not, we still abide by that, roughly, we just (as-if) remove
> dead stmts and phi nodes from the block before counting them.
Well, consider a block with 16 statements, 15 of which were dead.
Previously we wouldn't thread through that block.  Now we would thread
resulting in a tiny amount of codesize increase as there's a statement
to copy that would survive DCE.

But the effect should be very small and I think your testing results so
that to be true.

Jeff