Hi,

I'm writing a sophisticated DSL for working with linguistic parse trees, which is a set of top-level macros, each of which is comprised of sereval tens (up to 100 and more) other macros, that  heavily rely on special variables manipulation. Most of the macros are compiled OK, but in rare cases they cause the compiler to run out of memory (and I use dynamic-space-size of 3,5G).

The problem seems to occur inside SB-C::LIFETIME-POST-PASS, like in this stacktrace:

  0: (SB-C::INSERT-BLOCK-GLOBAL-CONFLICT #<SB-C::GLOBAL-CONFLICTS :TN #<SB-C:TN t1> :BLOCK # :KIND :LIVE> #<SB-C::IR2-BLOCK  :START-VOP # :LAST-VOP # :LOCAL-TN-COUNT 2 :%LABEL #<SB-ASSEM:LABEL 1>>)
  1: (SB-C::ADD-GLOBAL-CONFLICT :LIVE #<SB-C:TN t1> #<SB-C::IR2-BLOCK  :START-VOP # :LAST-VOP # :LOCAL-TN-COUNT 2 :%LABEL #<SB-ASSEM:LABEL 1>> NIL)
  2: (SB-C::SETUP-ENVIRONMENT-TN-CONFLICT #<SB-C:TN t1> #<SB-C::IR2-BLOCK  :START-VOP # :LAST-VOP # :LOCAL-TN-COUNT 2 :%LABEL #<SB-ASSEM:LABEL 1>> NIL)
  3: (SB-C::SETUP-ENVIRONMENT-TN-CONFLICTS ..)
  4: (SB-C::CONVERT-TO-ENVIRONMENT-TN #<SB-C:TN t1> #<unavailable argument>)
  5: (SB-C::CONFLICTIZE-SAVE-P-VOP ..)
  6: (SB-C::CONFLICT-ANALYZE-1-BLOCK #<SB-C::IR2-BLOCK  :START-VOP # :LAST-VOP # :LOCAL-TN-COUNT 14>)
  7: (SB-C::LIFETIME-POST-PASS #<SB-C:COMPONENT :NAME "PATTERN |Rule5/Case1|" {10030FB293}>)
  8: (SB-C::LIFETIME-ANALYZE #<SB-C:COMPONENT :NAME "PATTERN |Rule5/Case1|" {10030FB293}>)

...

Unfortunetely, I can't provide the example source code, because it's under NDA.

The processing, actually, seems to terminate eventually (if given enough time and memory), but it's taking pretty long (order of minutes) and for some examples falls into LDB with GC not having enough memory.

I've looked into the code of lifetime analysis in the compiler, but haven't found any explicit way to control its behavior.

I've also tried to experiment with different compiler policies: like setting debug to 0, compilation-speed to 0 or 3, speed to 0, space to 0, etc, but it didn't really make any difference.

Would be very obliged for any pointers on how to tackle this problem.

Best,
Vsevolod Dyomkin
+38-096-111-41-56
skype, twitter: vseloved