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)


Richard Kenner wrote:
>> Now, to the design issue at hand.  REG_LIBCALL_ID seems a better way to
>> represent libcalls than the longstanding begin/end structure for the
>> reason Danny stated: you can tell what instruction is in what libcall
>> without walking around in the instruction stream.  So, we don't want to
>> be removing it, we want to be moving towards it.
>>     
>
> For what it's worth, I agree.  It has always been a nuisance that we
> had such a poor structure to represent this and has always been the source
> of confusion in the past.
>
>   
>> 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 agree with this as well.
>   
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. And
during the dataflow branch developement, we corrected as many of these
as we encountered.  

For a long time, the gcc community has been happy "knowing" that it has
been wrong to insert code into a libcall and has been willing to simply
fix wrong code problems as they have been reported.  What we did was
make many of the cases where an insn is inserted into a libcall into a
compiler icing situation.  What has been extremely frustrating has been
Eric's personal attacks, by first calling this a "bug" and then calling
it "half backed."

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.  The community can then
test this to see how much of a problem this really is.  This is less of
"half baked" solution but, fixing libcalls was not actually the focus of
the dataflow branch.  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.  But vision of such
things are a lot better in hindsight.

Kenny


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