From: law@redhat.com
To: Diego Novillo <dnovillo@redhat.com>
Cc: Andrew Macleod <amacleod@redhat.com>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [tree-ssa] vdefs vs DCE
Date: Thu, 22 May 2003 18:22:00 -0000 [thread overview]
Message-ID: <200305221821.h4MILOXD005600@speedy.slc.redhat.com> (raw)
In-Reply-To: Your message of "22 May 2003 13:56:15 EDT." <1053626175.6937.30.camel@frodo.toronto.redhat.com>
In message <1053626175.6937.30.camel@frodo.toronto.redhat.com>, Diego Novillo w
rites:
>I fixed this particular idiocy with the new changes to remove
>INDIRECT_REFs as variables. In my local tree, I get this out of DCE:
>
>foo ()
>{
> (void)0;
> (void)0;
> (void)0;
> (void)0;
> (void)0;
> (void)0;
>
> bar ((char *)"fu", (char *)"bar", (char *)"com")
>}
Good.
>I think that the reason those T.x exist is because of the type casts
>that are going on.
Yes. Type casts cause us numerous problems. It's not just in argument
lists. They (*&@#$ us up in comparisons and just about everywhere else.
I suspect we're going to really need to re-think how we handle NOP
casting.
>It shouldn't be hard to have GIMPLE accept type
>casts in function arguments. Jason?
Well, I've already got a patch which does this. Or more correctly it allows
NOP casting in TREE_LISTs, which happens to be the biggest creator of
offending code like I noted above.
However, when I was looking at that, I realized that simpify_expr is doing
some really dumb things. For example, if you have something like a
NOP cast and your predicate is is_simple_val (which accepts NOP casts
on constants) simplify_expr still insists on mucking things up by
assigning the casted value to a new variable and using the new
variable whereever the cast originally was.
The root of this problem is that simplify_expr doesn't check the predicate
before simplifying. Ugh.
And we can't check the predicate before simplifying due to how we've
defined is_simple_stmt (always returns 1, which would prevent *any*
simplification).
Ideally we'd check that the operand fits the predicate and not simplify
which would make a lot of our casting issues go away. It might even
speed up the compiler (or it may slow it down -- I don't really know).
Arrggh.
Jeff
prev parent reply other threads:[~2003-05-22 18:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-22 14:55 law
2003-05-22 18:12 ` Diego Novillo
2003-05-22 18:22 ` law [this message]
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=200305221821.h4MILOXD005600@speedy.slc.redhat.com \
--to=law@redhat.com \
--cc=amacleod@redhat.com \
--cc=dnovillo@redhat.com \
--cc=gcc@gcc.gnu.org \
/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).