This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
More on SAVE_EXPR
- To: gcc at gcc dot gnu dot org
- Subject: More on SAVE_EXPR
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Tue, 13 Feb 01 17:36:02 EST
I thought I saved another message that I wanted to respond to, but I
guess not.
It was suggested that what we replace it with was a block structure
that contained an assignment to an anonymous VAR_DECL.
But I don't see how that solves any problems. Sure, for a scalar object,
you don't mind reusing the pseudo. But do you want to for memory? What's
the scope of that memory location in the VAR_DECL?
The problem of setting DECL_RTL in the VAR_DECL is not a whole lot different
that setting the SAVE_EXPR's RTL: if you can solve one, you can solve the
other.
The advantage of SAVE_EXPR is that it's much "lighter".
It seems we need some sort of mechanism to say "here's an expression that
I want to you evaluate 'from scratch'" in which case you want to treat the
SAVE_EXPRs in it as if they hadn't been evaluated. So why not have some
new node that says that? UNSAVE_EXPR is as good as any.