[Bug middle-end/5169] paradoxical subreg problem

[Bug middle-end/5169] paradoxical subreg problem

[jsm28 at gcc dot gnu dot org]

------- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-20 00:34 -------
The testcase no longer exhibits the bug, so this PR seems to represent
some underlying problem with compiler internals rather than any longer
being concerned with the failure of a particular testcase.

Jeff Law had a patch at <http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html>.
The discussion doesn't indicate anything in particular wrong with it,
was there some reason it wasn't applied?

The other bugs mentioned at <http://gcc.gnu.org/ml/gcc/2002-01/msg01802.html>,
bug 5185 and bug 5264 have both been closed on the basis that the listed
problems could no longer be reproduced, whether or not the underlying
compiler issue was still present.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu dot org
          Component|target                      |middle-end
            Summary|[PA-RISC] Bug in optimizer  |paradoxical subreg problem


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5169

[Bug middle-end/5169] paradoxical subreg problem

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-20 06:44 -------
(In reply to comment #7)
With respect to: <http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html>
and paradoxical subreg semantics on targets which support modes_tieable
(assuming that paradoxical subreg semantics applied to tied registers):

- It would seem that a paradoxical subreg need not have a memory operand
(as it would valid to be able to store a known lesser precision value in fewer
tied registers than the type that it logically represents may otherwise require)?

- nor does it seem to make sence in any circumstance to referance a wider
logical value than may be stored in a register or memory, without presuming
it's higher-order bits are of some known value (unless it's known that they're
logical value were to be effectivly replaced by the operation without regard to
it's initial value)?




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5169

[Bug middle-end/5169] paradoxical subreg problem

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-02-20 06:50 -------
(In reply to comment #8)
> - nor does it seem to make sence in any circumstance to referance a wider
> logical value than may be stored in a register or memory, without presuming
> it's higher-order bits are of some known value (unless it's known that they're
> logical value were to be effectivly replaced by the operation without regard to
> it's initial value)?

... or known not affect the operation (as would be typical of a shift count likely
never requiring more than a QI mode operand, although paradoxically a wider
operand may be formally required.) (it would seem)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5169

[Bug middle-end/5169] paradoxical subreg problem

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-02-21 14:14 -------
Subject: Re:  paradoxical subreg problem

On Sun, 2005-02-20 at 00:34 +0000, jsm28 at gcc dot gnu dot org wrote:
> ------- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-20 00:34 -------
> The testcase no longer exhibits the bug, so this PR seems to represent
> some underlying problem with compiler internals rather than any longer
> being concerned with the failure of a particular testcase.
> 
> Jeff Law had a patch at <http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html>.
> The discussion doesn't indicate anything in particular wrong with it,
> was there some reason it wasn't applied?
I don't think we ever came to a solid decision about which approach
was better.  My patch was simpler, but there may have been other
cases that Alan's patch handled that mine didn't.

I do think we all agreed that (subreg (mem)) was evil :-)

I think the fact that unrelated changes masked all these issues and
as a result this has been largely ignored for the last few years.

jeff



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5169

[Bug middle-end/5169] paradoxical subreg problem

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-02-21 17:34 -------
Subject: Re:  paradoxical subreg problem

On Mon, 21 Feb 2005, law at redhat dot com wrote:

> > Jeff Law had a patch at <http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html>.
> > The discussion doesn't indicate anything in particular wrong with it,
> > was there some reason it wasn't applied?
> I don't think we ever came to a solid decision about which approach
> was better.  My patch was simpler, but there may have been other
> cases that Alan's patch handled that mine didn't.
> 
> I do think we all agreed that (subreg (mem)) was evil :-)
> 
> I think the fact that unrelated changes masked all these issues and
> as a result this has been largely ignored for the last few years.

Perhaps we should apply both patches to eliminate this latent bug or bugs 
and allow the PR to be closed?  (After 4.0 branches given that the bug is 
apparently latent at present so we shouldn't need to risk these patches in 
4.0.)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5169

[Bug middle-end/5169] paradoxical subreg problem

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-02-22 16:58 -------
Subject: Re:  paradoxical subreg problem

On Mon, 2005-02-21 at 17:34 +0000, joseph at codesourcery dot com wrote:
> ------- Additional Comments From joseph at codesourcery dot com  2005-02-21 17:34 -------
> Subject: Re:  paradoxical subreg problem
> 
> On Mon, 21 Feb 2005, law at redhat dot com wrote:
> 
> > > Jeff Law had a patch at <http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html>.
> > > The discussion doesn't indicate anything in particular wrong with it,
> > > was there some reason it wasn't applied?
> > I don't think we ever came to a solid decision about which approach
> > was better.  My patch was simpler, but there may have been other
> > cases that Alan's patch handled that mine didn't.
> > 
> > I do think we all agreed that (subreg (mem)) was evil :-)
> > 
> > I think the fact that unrelated changes masked all these issues and
> > as a result this has been largely ignored for the last few years.
> 
> Perhaps we should apply both patches to eliminate this latent bug or bugs 
> and allow the PR to be closed?  (After 4.0 branches given that the bug is 
> apparently latent at present so we shouldn't need to risk these patches in 
> 4.0.)
Yea, I'd do it post 4.0.  I probably wouldn't even remember what changes
caused the bugs to go latent -- it's been that long :(

jeff




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5169

[Bug middle-end/5169] paradoxical subreg problem

[roger at eyesopen dot com]

------- Comment #13 from roger at eyesopen dot com  2005-12-04 18:06 -------
This bug has been fixed, and not just hidden.  Jeff Law's proposed solution to
this problem http://gcc.gnu.org/ml/gcc/2002-01/msg01872.html which was proposed
in January 2002, was contained as part of Jeff/HP's patch of April 2004 (which
is subversion revision 51785).

2002-04-03  Jeffrey A Law  (law@redhat.com)
            Hans-Peter Nilsson  <hp@bitrange.com>

        * combine.c (simplify_comparison): Avoid narrowing a comparison
        with a paradoxical subreg when doing so would drop signficant bits.

This explains why no-one was has been able to reproduce the problem since that
date, and assumed that it was hidden (had gone latent) by an unrelated change.
Since then that solution has been corrected/improved further by Ulrich in
revision 70785.

2003-08-25  Ulrich Weigand  <uweigand@de.ibm.com>

        * combine.c (simplify_comparison): Re-enable widening of comparisons
        with non-paradoxical subregs of non-REG expressions.


Alan Modra's (self-described) "band-aid" patch was never ideal.  It's not
unreasonable for combine to eliminate an AND expression with a read from
memory, if the paradoxical subreg semantics for the target imply zero
extension.
It's the later "unsafe" simplification of the comparison that was at fault.
Hence the current situation where simplify_comparison has been fixed, and
we don't have to needlessly disable a useful optimization with Alan's patch
is the most appropriate outcome.  Alan's work-around would have been suitable
for a release branch, if we didn't yet have the correct fix or such a fix
was too intrusive.


-- 

roger at eyesopen dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at eyesopen dot com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5169