From: Jeff Law <law@redhat.com>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: luisgpm@linux.vnet.ibm.com, Andrew Pinski <pinskia@gmail.com>,
sje@cup.hp.com, Richard Henderson <rth@redhat.com>,
Peter Bergner <bergner@vnet.ibm.com>,
gcc-patches@gcc.gnu.org, paolo.carlini@oracle.com
Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
Date: Thu, 06 Nov 2008 23:48:00 -0000 [thread overview]
Message-ID: <49137ABC.309@redhat.com> (raw)
In-Reply-To: <303e1d290811061452g1dae05efg7e6e52a112c32f5f@mail.gmail.com>
David Edelsohn wrote:
>
>
>>> find_base_term() either could check for non-zero base before returning
>>> in the lo_sum/plus/minus case statement or could handle lo_sum
>>> explicitly, like find_base_value().
>>>
>> I think my suggestion will accomplish the same thing -- and it makes logical
>> sense too -- if we can't determine something from the pointer reg, then we
>> look at other info, such as the symbol_ref within a lo_sum.
>>
>
> Yes, it will accomplish the same thing for this particular case.
>
> Currently find_base_value and find_base_term differ in their handling
> of LO_SUM. My question is whether this fix should maintain the difference
> in algorithms.
I suspect the differences are unintentional and one could easily argue
that find_base_value's handling of LO_SUM is better since LO_SUM has
pretty well defined semantics. One could also argue that both functions
shouldn't be so eager to return the results of the recursive call when
the recursive call returns NULL.
> Also, RTL alias analysis is very fragile and your suggestion
> may produce more accurate information in other situations, which could
> expose other latent bugs or unexpected behavior.
>
Part of the intent was to get the more accurate info in the presence of
registers marked with REG_POINTER. While it could expose latent bugs, I
think it's the right thing to do -- though we might look for a change
with a smaller impact for the upcoming release since I think we're in
stage3.
jeff
next prev parent reply other threads:[~2008-11-06 23:21 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-06 20:43 David Edelsohn
2008-11-06 22:05 ` Jeff Law
2008-11-06 23:29 ` David Edelsohn
2008-11-06 23:48 ` Jeff Law [this message]
2008-11-07 18:58 ` Luis Machado
2008-11-27 14:34 ` Luis Machado
2008-11-27 15:46 ` Richard Guenther
2008-11-27 20:32 ` Jeff Law
2008-11-27 21:07 ` Luis Machado
2008-11-27 23:24 ` Jeff Law
2009-05-26 16:50 ` Luis Machado
2009-06-01 3:55 ` Ian Lance Taylor
2009-06-01 15:21 ` Luis Machado
-- strict thread matches above, loose matches on Subject: below --
2008-09-16 18:21 Steve Ellcey
2008-09-16 19:00 ` Peter Bergner
2008-09-16 19:20 ` Steve Ellcey
2008-09-16 19:40 ` Peter Bergner
2008-09-16 21:55 ` Jakub Jelinek
2008-09-17 1:22 ` Peter Bergner
2008-09-16 19:44 ` Jeff Law
2008-09-16 20:20 ` Peter Bergner
2008-09-16 20:49 ` Jeff Law
2008-09-16 20:49 ` Steve Ellcey
2008-09-16 21:31 ` Jeff Law
2008-09-16 21:40 ` Steve Ellcey
2008-09-17 1:54 ` Peter Bergner
2008-09-17 17:31 ` Steve Ellcey
2008-09-18 16:03 ` Steve Ellcey
2008-09-18 20:38 ` Peter Bergner
2008-09-16 21:48 ` Jeff Law
2008-09-16 22:00 ` Steve Ellcey
2008-09-18 20:59 ` Richard Henderson
2008-09-19 18:56 ` Steve Ellcey
2008-09-23 20:55 ` Jeff Law
2008-09-23 21:08 ` Steve Ellcey
2008-10-03 19:35 ` Luis Machado
2008-10-04 0:47 ` Jeff Law
2008-10-04 1:09 ` Andrew Pinski
2008-10-16 21:46 ` Luis Machado
2008-10-16 22:02 ` Jeff Law
2008-10-30 22:27 ` Luis Machado
2008-10-31 2:23 ` Steve Ellcey
2008-10-31 2:17 ` Peter Bergner
2008-10-31 2:03 ` Jeff Law
2008-10-31 1:50 ` Steve Ellcey
2008-11-06 18:00 ` Jeff Law
2008-10-31 10:53 ` Jakub Jelinek
2008-10-31 20:29 ` Peter Bergner
2008-10-31 20:50 ` Luis Machado
2008-10-31 21:27 ` Jakub Jelinek
2008-11-06 18:25 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49137ABC.309@redhat.com \
--to=law@redhat.com \
--cc=bergner@vnet.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=luisgpm@linux.vnet.ibm.com \
--cc=paolo.carlini@oracle.com \
--cc=pinskia@gmail.com \
--cc=rth@redhat.com \
--cc=sje@cup.hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).