[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Help with RTL expand and a builtins
From:       Segher Boessenkool <segher () kernel ! crashing ! org>
Date:       2017-07-19 19:54:39
Message-ID: 20170719195439.GW13471 () gate ! crashing ! org
[Download RAW message or body]

On Wed, Jul 19, 2017 at 08:57:02AM +0200, Martin Liška wrote:
> On 07/18/2017 04:49 PM, Segher Boessenkool wrote:
> >On Tue, Jul 18, 2017 at 12:49:06PM +0200, Martin Liška wrote:
> >>Solved, tail call was responsible for dead RTL instructions.
> >
> >This seems similar to 
> >https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00362.html
> >then.  Is it?
> >
> >There are many cases where we generated dead code during expand on
> >purpose (some just laziness, some to avoid code complications).
> >Because of this it is hard to detect where we generate dead code that
> >is just plain wrong (should not be dead).  And such things aren't
> >trivial to debug :-(
> 
> Yep, exactly. It was really hard to debug! I tried many different 
> approaches how to
> generate sequence of RTL instructions and nothing :) Maybe writing to a 
> dump_file
> that RTL insns are eliminated will be handy?

The insns are deleted before expand dumps the insn chain; and the "we
expand this gimple to that RTL" part of the dump won't show it, either.

What I did before is complain when some code is inserted after a barrier
(i.e. without a label first).  That is pretty messy in itself, and there
really is no good place to dump it to dump file either.  (And avoiding
printing stuff for the harmless very common case where the function
return val reg is moved to a pseudo and then back again does is another
complication).

But that is a good idea: don't print where the insns are inserted, but
instead where they are deleted.  I'll try that.


Segher
[prev in list] [next in list] [prev in thread] [next in thread]