This is the mail archive of the 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)

Eric Botcazou wrote:
>> We added the LIB_CALL_ID because we foresaw that as we modernize the
>> rtl passes, that more and more of these passes will be using either
>> use-def or def-use chains.  For these optimizations, you rarely make
>> linear passes over the instructions, you simply follow the chains from
>> one insn of interest to another.
> Define "rarely". :-)  The only pass that uses REG_LIBCALL_ID is dce.c and the 
> first thing it does is a linear pass over the instructions...
>> 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.
There is nothing half baked at all about our implementation.
All of the insns between the one with the REG_LIBCALL and REG_RETVAL are
supposed to be part of the lib call.  According to Jakub, this insn that
has been inserted into the middle of the libcall has nothing to do with
the lib call and so it is a bug. 

I have to say that i am completely unrepentant about enforcing the
semantics of rtl.

>> I have not looked at this bug.  I am happy to if you want.  I am sure
>> that it will be trivial to modify the pass that moved/created the insn
>> in the middle of the libcall to inherit the LIB_CALL_ID from the
>> previous insn.
> As I said to Daniel, it's probably only the tip of the iceberg.
This is not true, the libcall_id addition was done very early in the
dataflow branch development cycle.  We fixed a lot of these bugs before
the dataflow merge was committed. I think that we can honestly say that
we are close to the end of this process rather than just beginning. 

This code in dce is going to fail whenever someone inserts code into the
middle of libcall and after the branch being committed several months
ago, and basically working on every single platform, this is the first
bug that has surfaced since the commit. 


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