This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [tree-ssa] Fix variables getting out of their scope


In message <20030811191953.GB7767@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak writ
es:
 >Hello,
 >
 >> > > If not, then I would vote for moving *all* local declarations to the to
 >p
 >> > > BIND_EXPR and remove all BIND_EXPRs inside the function.  IIRC, I once
 >> > > suggested something along those lines but it didn't turn out to be a
 >> > > good idea because it would break debugging info.
 >> > This would break debugging regardless of optimization level. Zdenek's
 >> > change only causes debugging info to break when we can't avoid it.
 >> > One is acceptable to gcc, the other is not.
 >> >
 >> Moving all local declarations to the top BIND_EXPR would only occur with
 >> optimization.  By what you said earlier, it should also be OK.  I don't
 >> understand the distinction you're making here.
 >
 >well, there is one important distinction -- I only clobber the debugging
 >information when neccessary, which is more acceptable than breaking it
 >altogether.
 >
 >Then there are two problems:
 >1) moving variables to the outer scope might pessimize the code a bit.
Possibly.

 >Now when the variables are in disjoint scopes, they may get the same
 >stack slot assigned (if any).  Not really sure whether we use this,
 >though.
Addressable variables in disjoint scopes are allowed to share stack slots.
However, we shouldn't be extending the lifetime of anything addressable.

[ Note that I'm not advocating fixing this problem, just clarifying what
  happens in the backend. ]


Note that blindly moving variables to an outer scope may have impacts on
languages were variables are constructed/destructed -- suddenly the destructors
don't run when you expect them.

jeff


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