This is the mail archive of the
mailing list for the GCC project.
Re: PR optimization/9786
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 16 Sep 2003 23:28:05 -0400 (EDT)
- Subject: 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 email@example.com
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)