Comments on: Conundrum

By: tom

tom — Fri, 06 Jul 2007 16:36:56 +0000

That plan won’t work either. In the full incremental case, there would never be a nice way to unsmash a decl — but we definitely need this.

Instead I’m going to have a per-thread hash table mapping unmodified decls to their smashed variants. Then I’ll audit the C front end to add hash lookups everywhere they are needed. Not fun but it will give the correct answer in all the scenarios.

By: tom

tom — Sat, 30 Jun 2007 07:52:11 +0000

Maybe another idea is to change the game a little bit — warn if two decls are smashed, and use the combined decl. Underlying this approach is the hope that smashing decls is uncommon. Some emperical data here would be useful.

By: tom

tom — Fri, 29 Jun 2007 21:14:01 +0000

The problem with using copy-on-write is kind of obscure. I keep forgetting it . Anyway, I think the problem is that GCC compares trees like this using ==, so object identity is important. This is why smashing decls together is done, and this is why all the uses have to refer to a single decl. I need to investigate this a bit more — maybe this is the weak point where a change can be made.

Alternatively I thought of a complicated solution involving recording all the hunks that modify a decl, and then only allowing hunk reuse if all the modifying hunks are used by the compilation unit. This is kind of nasty though, and harder to reason about; for instance one of these hunks may have unsatisfied dependencies, so you may need a relatively hairy dependency check, or you may need to do all the dependency checks before doing any parsing.

By: Alexander Larsson

Alexander Larsson — Fri, 29 Jun 2007 06:51:48 +0000

Yeah, some form of copy-on-write seems to be the best way. Perhaps saving the old version in some form of backlink and somehow tagging each version so you know what compilation unit the modifications came from.

By: Stuart Ballard

Stuart Ballard — Thu, 28 Jun 2007 22:24:19 +0000

How about every time the compiler wants to modify one of these objects, take a copy of it, and use the copy for the thread that needs to modify it, leaving all other instances sharing it using the unmodified original.

If it’s possible to detect how many times it’s already being shared you could optimize away the copy in the case where it’s not, yet, but you’d have to add a flag to indicate that if it’s to be shared in future it’ll need to be recreated fresh…