Remove some more unused code from ia64 back end.

[James E Wilson]

On Thu, 2004-07-29 at 14:55, Zack Weinberg wrote:
> James E Wilson <wilson@specifixinc.com> writes:
> > You apparently did not look very hard.  The use of it disappeared in
> > between gcc-3.2 and gcc-3.3.
> Then the change that got rid of the need for it does not mention this
> in the ChangeLog.  I'm not sure how else I should have looked.

ChangeLogs can not be relied on for such info.  If the only thing you
looked at was current sources, then you can not make the claim "appears
never to have been used".  The only claim you can make is that it is not
used in current sources.  If you want to make the claim that it has
never been used, then you actually have to look at old gcc sources,
which is what I did.

There are several ways to do this.  What I did was grep through copies
of old gcc versions.  Another way to do this is to search through cvs,
by checking out old revisions of the file.

By the way, it isn't hard to find the patch that removed the use of
setjmp_operand.  You just didn't try.  Either method mentioned above can
be used to locate it.

In any case, it doesn't really matter.  It is unused, and removing it
was fine.  The only problem here was that you made a misleading claim
about the IA-64 port, and when you do that, I have to correct you.

> I would prefer not to put it back exactly as it was, since it makes
> use of the currently_expanding_to_rtl hack.  Given the way it is used,
> i.e. exclusively in *load_symptr_high and *load_symptr_low, which
> appear only to be generated as a consequence of calling
> ia64_expand_load_address, I believe that test to be unnecessary.

Yes, this is OK, though I note that you made no mention of this when you
removed the code, so I didn't know this was an issue.

> Also, it appears that the spurious 'return 1;' was dislocated from the
> case SYMBOL_REF: below, so that case is incorrectly failing always.

That is obviously not correct.  Both parts of this claim are wrong, the
part about where the spurious 'return 1;' came from, and the part about
the current code failing.  It is trivial to see that the first claim is
wrong by looking at the URL I included in my last message.  Since you
did not bother to look at this, I can only conclude that you don't care
enough about IA-64 to get it right, in which case you should not be self
approving patches for the IA-64 port.

For the second claim, the code obviously has a deliberate fall through
that is uncommented, and hence it does work, though this is a poor
coding style.

Fortunately, the patch you added is harmless, and improves the code
style.  Still, I'm unhappy that you are doing such poor quality work
here with all of these false claims.  I expect better from a global
write maintainer.

> I'll test the appended patch on ia64-hpux.  Could you give an example
> of the sort of code that should be optimized better with the extra
> tests in place, so that I can make sure it works?

I don't have one offhand.  It should be possible to generate one
yourself by compiling some code with the patch and without it.

In any case, I don't think that is really necessary.  The code is
supposed to be there.  We want it to be there.  The only thing wrong is
the spurious 'return 1;' that needs to be removed.  I would be satisfied
with just putting the code back without the return 1 and the
currently_expanding_to_rtl hack.

If you don't like that suggestion, then put the code back with the
spurious 'return 1;' and without the currently_expanding_to_rtl hack,
file a bug report, and I will look at it.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com