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]
Other format: [Raw text]

Re: [PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)


xf. http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00886.html
(sorry for breaking the thread)

Eric Botcazou wrote:
> > The LIB_CALL_ID provides a simple constant time test to find out if you have
> > landed inside of a lib call.  Removing this structure will only make it
> > harder to add passes that only deal with the instructions of interest and
> > essentially forces us into the endless inefficient rescanning of blocks
> > paradyme that the rtl passes are famous for.
>
> OK, but it's half-backed work since only the new dce.c pass among the RTL
> passes knows of it, and GCC is also famous for its half-back transitions.

I can't resist reacting to this.

First, the only reason why there are so many "half-back transitions"
is because no maintainer can do a full transition by him/herself.  The
main reasons for this, as I see it, are that there is no coherent plan
for the development of GCC, and there are too many would-be
maintainers who only feel responsible for their own little niche
interest and not for the overall cleanliness of GCC.  I don't see you,
Eric, help with e.g. the mapped-locations support, the transition to
define_peephole2, or this ugly libcall notes mess that's given me too
much gray hair already over the past five years.  Only the bravest
developer with very thick skins still dare to make a significant
change to the GCC code base (I particularly admire Diego for this ;-).

FWIW an old and by now incomplete list of partial transitions is in
the wiki: http://gcc.gnu.org/wiki/Partial_Transitions.


But what I'm missing here (perhaps because I only half care about GCC
anymore myself, so I don't follow what is going on, but hey! ;-) is
why there is any reason to still have REG_LIBCALL and REG_RETVAL notes
at all.

The only reasons left to have these libcall notes, as I recall, were:

1) the old RTL loop optimizer could use them to move loop invariant libcalls.
Since the old RTL loop optimizer is no more, this is no longer a
reason to keep the old-style libcall notes.

2) the old DCE in flow.c could remove entire libcall sequences if the
libcall result was dead.
The new DCE uses REG_LIBCALL_ID notes, so again the reason to have
REG_LIBCALL and REG_RETVAL is gone here.

3) The pre-regalloc scheduling pass used to move libcall blocks as a whole.
I don't know if this is still the case, and I also don't really see
why this was ever necessary to begin with.  But if this is still
necessary for some targets, then you should be able to schedule all
insns with the same REG_LIBCALL_ID notes as a block.


So, if anyone is considering to actually complete this transition, I'd
suggest removing REG_LIBCALL and REG_RETVAL and teaching the scheduler
to move insns with the same REG_LIBCALL_ID as a block.  This should
even be quite safe for GCC 4.3.

My $0.02.

Gr.
Steven


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