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)


Kenneth Zadeck wrote:

>>> But, because we're presently dependent on the old structures, it sounds
>>> to me like we need to make sure that no non-libcall instructions are
>>> inserted between REG_LIBCALL and REG_RETVAL.  That's the bug.  

> I think that this is the fundamental point. Danny and I have taken the
> view that it is not correct to insert instructions into a libcall. 

> I will post a patch today that, rather than just waiting for dce to try
> to delete a libcall with a problem, aggressively checks each pass to
> make sure that no one has inserted such an insn.

That seems like a good thing; verification of invariants is nice.

> I happen to be of the mind that libcalls are just
> bad and that our time would have been better spent removing them rather
> than trying to make something this busted work. 

Let's be careful about terminology here.  Libcalls aren't "busted".
Certainly, one can build a working compiler with the old libcall
representation, the new one, or no such representation at all.  I think
one of the reasons we tend to get each other worked up is that we
declare things "hopelessly broken", "totally busted", etc. too often.
Some of us have worked hard to build these things now being declared
"busted". :-)

Anyhow, it would certainly be a priori better if libcall sequences in
RTL could just go away and the "magic" properties of libcall sequences
be otherwise expressed in some generic form.  As Jakub says, part of the
idea is to be able to delete libcalls wholesale when you realize you
don't need their values; we might now be able to set things up so that
our ordinary code-removal optimizations just automatically do that.
We'd certainly need something to say that a function call instruction is
deletable if its value is unused; in general, of course, we assume
function calls have important side-effects.

Anyhow, I'm not seeing any reason for drastic action here.  It seems to
me like REG_LIBCALL_ID gives us a path forward, so we want to keep it.
Meanwhile, we need to fix this bug.  I haven't seen anything so far that
suggests that fixing the bug requires a major change to the
representation; it just sounds like a bug.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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