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: PR optimization/9786

>> Is it ok to delete a no-op insn that can trap? 
> The question is simple, but probably not specific enough. As it stands,
> the answer is probably no. But, in reading the referenced message, it
> sounds like we know that the no-op doesn't trap, and therefore, we can
> change it, optimize it based on the knowledge that it doesn't trap and
> therefore, delete it.

What about an unnecessary PIC symbol reference accessed through the

I don't I understand the rules for -fnon-call-exceptions.  On
the PA the rules for the trapping of floating point instructions are
very complex.  A symbol reference via the reference shouldn't normally
trap but almost any instruction can trap if there is a system TLB
or in the case a problem with the got pointer.

We emit a lot of insns in the initial rtl generation that we wouldn't
emit if we were smarter.  The current rules say an insn that loads
a symbol reference containing an unspec in a MEM may trap, so it can't
be deleted.  On the otherhand, the insn may be logically unnecessary to
the behavior of the code and probably didn't have to be emitted in
the first place.  So, where do we draw the line in optimizing rtl?

J. David Anglin                        
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

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