This is the mail archive of the gcc-bugs@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]

Re: Problem with auto-inc code (ARM)



> >Unfortunately, this leaves the log_links of insn 5856 pointing at the
> >deleted insn, which trips the checking code in combine when we try to get
> >the links from the deleted insn as part of a three-way combine.
> >
> >I guess the correct thing to do is to update the links correctly, but I'm
> >not particularly familiar with the data structures used in flow.  Is there
> >a simple way to find insn 5856 when we delete the increment?
> >
> >If this isn't feasible I can see two other approaches:
> >
> >1) we could modify combine_instructions to check that an insn hasn't been
> >deleted before we try to dereference its links.  I don't like this, since
> >it's really papering over a crack.
> >
> >2) We could turn the insn that we have deleted into a no-op move so that
> >it is never deleted (this is essentially what would happen if the
> >increment insn had written its result to a different register with the
> >source register dying in the insn); but there is a comment in there that
> >says that it should be deleted so that it doesn't appear as a "use and a
> >set" of the reg.
> 
> Hmm, it seems to me remove_dependence(insn,elem) in haifa-sched.c does part 
> of what we want. Can't we have a cleanup pass at the end of flow looping 
> over the insns with an insn_list?
> 

I've been thinking about this, off and on, over the past few days.  I 
think we may need to redirect any such link rather than remove it.  Doing 
that is not hard, once we have found the appropriate insn (I believe there 
can't be more than one in a block);  finding the insn isn't that hard 
either, just a bit expensive since we don't have any information cached 
(to cache it, we would have to track the next two uses of a register, 
rather than just the next single use). So the important questions are:

 i) Would combine be able to make use of a log_link to an insn with an 
auto_inc side-effect?
 ii) If not, would deleting the link lead to an inaccurate dependency 
graph that would cause mis-optimizations later on?

Richard.



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