http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041

Vladimir Makarov <vmakarov at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at redhat dot com

--- Comment #3 from Vladimir Makarov <vmakarov at redhat dot com> ---
I guess RA is doing right thing.  Pseudo 84 corresponding to variable sum when
the second printf is uncommented lives through insn throwing an
exception.  The code affecting p84 allocation (putting it into memory
as SSE_REGS have no caller-saved regs) is

ira-lives.c::process_bb_node_lives:

                  if (can_throw_internal (insn))
                    {
                      IOR_HARD_REG_SET (OBJECT_CONFLICT_HARD_REGS (obj),
                                        call_used_reg_set);
                      IOR_HARD_REG_SET (OBJECT_TOTAL_CONFLICT_HARD_REGS (obj),
                                        call_used_reg_set);
                    }
Where insn is:

(call_insn 141 140 142 22 (call (mem:QI (symbol_ref:DI ("_ZdlPv") [flags 0x41]
<function_decl 0x7ffff1ae2400 operator delete>) [0 operator delete S1 A8])
        (const_int 0 [0]))
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/new_allocator.h:100
648 {*call}
     (expr_list:REG_DEAD (reg:DI 5 di)
        (expr_list:REG_EH_REGION (const_int 0 [0])
            (nil)))
    (expr_list:REG_FRAME_RELATED_EXPR (use (reg:DI 5 di))
        (nil)))

it is a destructor in new_allocator.h:

      void
      deallocate(pointer __p, size_type)
      { ::operator delete(__p); }

The problem could be solved by p84 live range splitting.  By default IRA does
live range splitting only when the register pressure is high.  This is not the
case for the test where max pressure for GENERAL_REGS and SSE_REGS is only 4.

We can modify semantics -fira-region=all to form a region for any loop on which
border live range splitting is done.  I tried that and with -fira-region=all
the same speed is achieved for the test.  Unfortunately, with the new semantics
permitting too aggressive spilling, the generated code is about 0.5% worse on
SPEC2000 for x86-64.

I guess we should pay more attention in optimizations to deal with code with EH
regions, as C++ code have a lot of such code.

I'll think what can I do more with the problem.

Reply via email to