public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kenneth Zadeck <zadeck@naturalbridge.com>
To: Toon Moene <toon@moene.indiv.nluug.nl>
Cc: Jakub Jelinek <jakub@redhat.com>,
	  Richard Guenther <richard.guenther@gmail.com>,
	  gcc-patches@gcc.gnu.org,
	Nathan Froyd <froydnj@codesourcery.com>,
	  Mark Mitchell <mark@codesourcery.com>,
	 Diego Novillo <dnovillo@google.com>
Subject: Re: [lto] set alias info, poorly
Date: Mon, 10 Dec 2007 20:02:00 -0000	[thread overview]
Message-ID: <475D9B19.8050808@naturalbridge.com> (raw)
In-Reply-To: <475D9994.200@moene.indiv.nluug.nl>

Toon Moene wrote:
> Kenneth Zadeck wrote:
>
>> If you want to ask a question about two types, the first part of
>> that check will to see if the types come from the same front end.  If
>> they do, then this issue can be resolved by asking some language
>> dependent code that will be located in the middle end of the compiler. 
>
> Well, that will mean that it'll be a fascinating piece of "language
> dependent code [...] located in the middle end of the compiler".
>
> The Fortran rules are basically:  If you don't *tell* the compiler
> (hence the front end) that two items alias, they don't.
>
> I think this means that LTO *with* Fortran-sensible alias analysis
> will only work if the Fortran front end actually determines alias
> equivalence sets and passes that down to the middle end, which then
> (in this magically "language dependent code") has to do something
> intelligent with it ...
And then we will need to "merge" that info as we bring in the code for
other fortran modules. 
i am not happy about going down this path, but the loss of that info is
not a good choice either. 

Consider the java case where two pointers cannot alias unless the type
of one pointer is derived from the other.  This means that most pointers
do not alias rather than the c/c++ case where most pointers can possibly
alias.

>
> Hmmmm, magic ...
>

  reply	other threads:[~2007-12-10 20:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-06 22:29 Nathan Froyd
2007-12-07 10:47 ` Richard Guenther
2007-12-07 10:59   ` Jakub Jelinek
2007-12-10 13:55     ` Kenneth Zadeck
2007-12-10 19:55       ` Toon Moene
2007-12-10 20:02         ` Kenneth Zadeck [this message]
2007-12-10 20:09           ` Richard Guenther
2007-12-10 20:49             ` Kenneth Zadeck
2007-12-10 21:00               ` Richard Guenther

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=475D9B19.8050808@naturalbridge.com \
    --to=zadeck@naturalbridge.com \
    --cc=dnovillo@google.com \
    --cc=froydnj@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=mark@codesourcery.com \
    --cc=richard.guenther@gmail.com \
    --cc=toon@moene.indiv.nluug.nl \
    /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).