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)


> > These REG_LIBCALL_ID notes would need to be actively maintained
> > throughout the entire RTL middle-end
>
> Yes, but that is equally true for REG_LIBCALL and REG_RETVAL, which
> currently give GCC a lot of trouble, too.

No, not equally true, REG_LIBCALL and REG_RETVAL are already actively 
maintained throughout the entire RTL middle-end.  Granted, with more
or less trouble, but they are.

> From my POV, one advantage of REG_LIBCALL_ID is that all insns that
> are part of a libcall sequence are explicitly marked as such.  This
> should in theory make it easier for the optimizers to work with the
> insns stream, because you can immediately tell whether an insn belongs
> to a libcall sequence.  This ought to make it possible to insert
> non-libcall insns into the libcall sequence without making it part of
> the libcall. That, in turn, would allow the compiler to move around
> insns that are part of a libcall. Think e.g. code hoisting or PRE,
> when an expression can be hoisted, but one insn is in a libcall and
> the other is not -- gcc currently can't hoist in a case like this.
> I'm sure similar restrictions due to libcall notes apply most other
> RTL passes.  With REG_LIBCALL_ID, most of these restrictions would be
> lifted.  Another common problem with the old libcall notes is that you
> frequently have to move the notes to another insn in the libcall
> sequence.  With REG_LIBCALL_ID you wouldn't have this problem because
> all libcall insns carry a libcall note already.

I agree that it could be convenient to allow REG_LIBCALL_IDed insns 
interspersed with non-REG_LIBCALL_IDed insns.  But I think that this
would need some serious thinking because you need to precisely define
when the REG_LIBCALL_ID flag is inherited or not (see Jakub's example).

> Of course another solution is to keep the libcall insns sequence
> contiguous, but in that case REG_LIBCALL_ID is just overhead to keep
> one pass happy.  It would not solve any of the issues with the old
> libcall notes.

Right, I also think that requiring REG_LIBCALL_IDed insns to be contiguous 
voids any advantages over REG_LIBCALL and REG_RETVAL in practice.

> Yet another solution is to implement TLS_ADDR_EXPR and remove libcall
> notes altogether, but that is (and has been for years now)
> pie-in-the-sky, it seems :-(

Definitely, I'm personally not too thrilled about inventing yet another brand 
new mechanism to deal with libcalls.  If you have some time to divert to GCC 
in the near future again, I'd be happy to explore some definitive solutions 
on a branch.

-- 
Eric Botcazou


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