www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9922] New: Improve symbol emitting for templates for better separate compilation support

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9922

           Summary: Improve symbol emitting for templates for better
                    separate compilation support
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: m.strashun gmail.com


--- Comment #0 from Dicebot <m.strashun gmail.com> 2013-04-11 11:09:58 PDT ---
Currently all of them are generated to object file associated with module
supplied to the command line. For separate compilation scenario that means that
ALL template symbols from ALL imported modules are emitted into compiled single
module.

Most time it is just extra job for linker, but sometimes this results in nasty
bugs when resulting symbols are not weak ones.

Desired behavior: dmd will tries to find root module where template
instantiation chain has started via call from non-templated scope.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 11 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9922


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code dawg.eu


--- Comment #1 from Martin Nowak <code dawg.eu> 2013-04-11 16:39:25 PDT ---
(In reply to comment #0)
 Most time it is just extra job for linker, but sometimes this results in nasty
 bugs when resulting symbols are not weak ones.
I'd say this is a bug, any templated symbol must be weak. Do you have a test case for this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9922



--- Comment #2 from Dicebot <m.strashun gmail.com> 2013-04-12 00:26:12 PDT ---
(In reply to comment #1)
 (In reply to comment #0)
 Most time it is just extra job for linker, but sometimes this results in nasty
 bugs when resulting symbols are not weak ones.
I'd say this is a bug, any templated symbol must be weak. Do you have a test case for this.
Please correct me if I am mistaken, but this is one of the issues causing http://d.puremagic.com/issues/show_bug.cgi?id=9571 as far as I am understand. When auto return type is used, foo is processed as a template instance and all symbols it uses, including problematic lambda, come to a.o via MapResult. There are plenty of reason that make problem observable : wrong id for funcliteral, fact that foo is treated as template instance when it is actually not, fact that all symbols used from templates go to command-line supplied module. Well, that is my interpretation of what gdb has told me, I am complete and utter noob in dmd internals, so please object. And yes, this behavior is a bug for sure on its own. That is why I have marked this issues as an enhancement and not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9922



--- Comment #3 from Martin Nowak <code dawg.eu> 2013-07-19 16:40:11 PDT ---
We had another Bugzilla for link errors with separate compilation but I can't
find it.
There I mentioned that the correct compiler behavior would be to emit a weak
template instance to each object file that references that instance.
This has some performance issues but it only affects separate compilation with
multiple object files.
One approach to mitigate the performance impact would be something like partial
linking, i.e. producing the duplicated template instances at binary level not
at AST level.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 19 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9922



--- Comment #4 from Dicebot <public dicebot.lv> 2013-07-19 17:50:18 PDT ---
(In reply to comment #3)
 There I mentioned that the correct compiler behavior would be to emit a weak
 template instance to each object file that references that instance.
 This has some performance issues but it only affects separate compilation with
 multiple object files.
Yes, that is my understanding too. However, implementing this may be much trickier than it sounds because currently DMD front-end does not really track object files that need to reference instance in any convenient fashion. At least I could not find a straightforward way. Another issue is that template instances are re-used and only context of first usage gets fully saved (again, that is what trial-and-error have shown to me). We have discussed that briefly in matching (failed) pull request by eskimor. However, I expect in the end performance to actually improve because those few extra weak symbols per module object file are minority comparing to all templates that get used only by constraints and CTFE and can be completely ignored during symbol emitting. If compiler becomes more aware of actual template usage (from ABI point of view), some useful optimizations can be done here. Are you referring to this "won't fix" issue http://d.puremagic.com/issues/show_bug.cgi?id=3274 ? Anyway, I am trying to hack together some proper solution here, to address both separate compilation and template bloat issues, but it is likely to take hell of a long time, dmd code in this part is far from obvious. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 19 2013