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]

Re: A patch for gcc.c-torture/execute/980505-1.c



  In message <m0ynYQA-00026CC@ocean.lucon.org>you write:
  > > 
  > >   > > Change this to (set && in_libcall) since we do not need to make any
  > >   > > of these transformations unless we are in a libcall block.
  > >   > > 
  > >   > 
  > >   > That is not true. Please see the enclosed RTL dump. When we delete
  > > I think this means you've misunderstood how I wanted this problem
  > > fixed.
  > > 
  > > To delete insns 9 and 22 we have to modify insns in the libcall block
  > > itself (insns 11 and 24 respectively).  We should be keying this
  > > on changes in the libcall block only.  Anything else is wrong.
  > 
  > Why do I have to fix insns 11 and 24. egcs handles them correctly. The
  > problem is the REG_RETVAL notes on insn 17 and 30. Please see the RTL
  > dumps enclosed here before and after delete_trivially_dead_insns.
Sorry, I stated that poorly.

It is CSE's modification of insns 11 and 24 that makes insn 9 and 22 dead.

So, at some point CSE modifies insns in the libcall -- we can detect this
and fix the notes for the effected libcall.  It is wrong to fix any other
notes or notes for other libcalls.  Your patch is simply wrong.

--

I looked into two other ways of attacking this problem; the first based
on the fact that pseudos used in libcalls are supposed to be totally unused
after the libcall.  In thise case reg:SI 23 is used in two libcalls, which
we could argue is the core problem.

We could fix this by generating a new pseudo for each libcall, then copying
reg 23 into the new pseudos outside of the libcall.  Inside the libcall we
could replace reg23 with our new pseudos.

This ought to be easy, but I couldn't make it work -- we have to play
around with generating new sequences for the copy and splicing them into
the existing chain.  For reasons I don't understand I couldn't ever get
the splicing code to work correctly.

This may be the best approach.

--

The second approach was to fix the notes at the same time as we modify insns
in the libcall sequence.  This may actually be beneficial since it propagates
constants into the retval notes, which make expose more redundant libcalls.


--

The last is to try and fix the notes in delete_trivially_dead_insns, but
the more I think about the problem the less I like this approach.


jeff


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