This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

More on SAVE_EXPR


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]