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)


> First, the only reason why there are so many "half-back transitions"

Sorry for the typo, I meant "half-backed 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 fully agree with you.

> I don't see you, Eric, help with e.g. the mapped-locations support,

Look more carefully: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01976.html

> 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.

Right.

> 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.

Wrong.  The new DCE handles libcalls backwards, i.e. as optimization barriers 
(see Jakub's messages) instead of as optimization helpers.

> 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.

These REG_LIBCALL_ID notes would need to be actively maintained throughout the 
entire RTL middle-end and I don't see any practical advantages over what we 
currently have.  And of course someone needs to do the implementation.

> 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.

I'd suggest to take a look at the handling of libcalls in dce.c...

-- 
Eric Botcazou


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