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)


Steven Bosscher wrote:
> 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
>   
I think that when danny and i started this, it was not considered an
option to remove libcall notes.  I never understood the reason for them,
but in retrospect it most likely would have been easier to get rid of
them rather than take the route we did an actually make them work the
way they were supposed to. 


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