This is the mail archive of the 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: [patch] fold-const.c (fold): Clean up use of variable "t".

Hi Roger and Richard,

> I really like this clean-up, but as Richard Kenner has suggested
> the shadowing of "t" can be confusing, and without "shrink-wrapping"
> can lead to larger stack frames for fold, which is often recursive.

I thought I was manually doing -fweb, splitting live ranges of "t"
into smaller pieces, but then the current register allocator may not
assign more than one variable to a stack slot AFAIK.

> Fortunately, most of the cases that you clean-up, require very short
> life-times/scopes for the new local "t".  In these cases, I'd recommend
> using the fold-scope "tem" variable.

OK.  I will submit a revised patch.

> However, I really like the concept of making "t" const, and completely
> removing "orig_t".  For the remaining difficult cases you might consider
> a recursive call to fold with the modified t, or alternatively you could
> rename all uses of "t" between its modification and the next "return t".

I would go for renaming.

> Once this is done, I think we might be able to remove the fold_1 wrapper
> used by --enable-checking=fold, as we should be able guarantee the input
> tree is immutable (i.e. that fold is nondestructive).

Err, there is no guarantee that inner expressions stay untouched, so
we may still need --enable-checking=fold.

Kazu Hirata

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