Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REG2.064a] Issue 10726 - Bogus Circular Reference error if opEquals defined and has a loop #2421

Merged
merged 2 commits into from Aug 12, 2013

Conversation

9rnsr
Copy link
Contributor

@9rnsr 9rnsr commented Jul 30, 2013

* directly compiled, the target TypeInfo symbol would already
* exist in separately compiled object file.
* So don't generate it again.
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid this assumption is not true. If the declaration is in a .di file (like in deimos), the module itself is never compiled.

I have tried to fix http://d.puremagic.com/issues/show_bug.cgi?id=10442 by adding semantic3 to the TypeinfoDeclaration types, but I'm not sure yet whether that causes too much bloat: rainers@b1a8e1b

@9rnsr
Copy link
Contributor Author

9rnsr commented Aug 2, 2013

Superseded by #2444.

@9rnsr 9rnsr reopened this Aug 5, 2013
@9rnsr
Copy link
Contributor Author

9rnsr commented Aug 5, 2013

This fix does not add any new semantic phase. Instead TemplateInstances require deferred semantic3.

* the TypeInfo object would be speculatively stored in each object
* files. To set correct function pointer, run semantic3 for sd->xeq.
*/
if (FuncDeclaration *xeq = sd->buildXopEquals3(NULL))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is good to run semantic3 at this stage of compilation as object file generation has already begun but the AST might get changed by semantics.
I also consider all calls of getTypeInfo(NULL) at this stage as bugs, but they seem ubiquitous.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See latest change. Now semantic3 is not invoked in glue layer.

@9rnsr
Copy link
Contributor Author

9rnsr commented Aug 9, 2013

I updated this PR.
Now, struct semantic3 is run for __xopEquals and __xopCmp if needed, and addDeferredSematnic3 is used for that. All work is done in front-end layer, so this is the best way I can think.

@@ -114,6 +117,10 @@ void AggregateDeclaration::semantic3(Scope *sc)
//printf("AggregateDeclaration::semantic3(%s)\n", toChars());
if (members)
{
StructDeclaration *sd = isStructDeclaration();
if (isImportedSym(sd))
goto Lxop;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can skip RTInfo generation for imported aggregates here, they also go into the TyeInfo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know there would be another issue, but it is not directly related to bug 10726. So, I won't fix RTInfo issue in this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be a regression on symbols from imported modules that never generate RTInfo after the change? But maybe they have never done that...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Currently, just imported non-template struct does not instantiate RTinfo and store the code to the importing module obj file, because semantic3 is never run for those structs.

By this change, semantic3 will be invoked for some non-template structs even if it is just imported. To keep the current behavior, this goto is necessary.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Thanks for the explanation.

@rainers
Copy link
Member

rainers commented Aug 9, 2013

Now, struct semantic3 is run for __xopEquals and __xopCmp if needed, and addDeferredSematnic3 is used for that. All work is done in front-end layer, so this is the best way I can think.

Thanks, much better now.

I'm currently trying to get rid of getTypeInfo() calls (mostly from the backend) that add new AST nodes that are never analyzed, or write incomplete info directly to the object file. Part of that is to add the TypeInfoDeclaration to deferredSemantic3 and add a semantic3 pass to it. Maybe this could also trigger buildXopEquals and buildXopCmp.

On the other hand, if your patch also includes the RTInfo generation for all structs, it might solve the troubles with getTypeInfo(NULL) (probably not completely for associative arrays), but it could also cause code bloat.

@@ -701,6 +732,16 @@ void StructDeclaration::semantic(Scope *sc)

buildOpAssign(sc2);
buildOpEquals(sc2);

xeq = buildXopEquals(sc);
xcmp = buildXopCmp(sc);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see it is identical to what was previously done in semantic2, but should this use sc2 instead of sc?

[Sorry if I'm asking dumb questions, but without having a complete overview of the implications, I just want to make sure that if something looks suspicious to me, it is not an oversight.]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ouch, that's my copy-paste mistake. Fixed.

rainers added a commit that referenced this pull request Aug 12, 2013
[REG2.064a] Issue 10726 - Bogus Circular Reference error if opEquals defined and has a loop
@rainers rainers merged commit 4e9a7b1 into dlang:master Aug 12, 2013
@don-clugston-sociomantic
Copy link
Contributor

This pull request slowed down DMD unittest compilation dramatically. Compilation now takes 15% - 20% longer on all platforms.
eg, Win64 went from 22minutes to 25.5 min. Linux 32 went from 5.5 min to 6.5 min.

Phobos test time barely changed (~2%), so it is possible that most of the time increase happens only on particular tests.

@ghost
Copy link

ghost commented Aug 19, 2013

I don't know whether it was this pull, but timings for building a simple test file have exploded:

module test;
import std.stdio;
void main() { }

2.063.2:
392 msecs

Git-head (1a6da16):
1251 msecs

I've reported this in d-internals (but the post awaits moderation approval).

scx->scopesym->members && !scx->scopesym->isTemplateMixin()
if (scx && scx->scopesym && scx->scopesym->members &&
!scx->scopesym->isTemplateMixin() &&
!scx->scopesym->isModule()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems this change has caused the reported performance regression.
Actually, the line below could have hinted in that direction.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@9rnsr I've run the tests successfully without the isModule check, do you think it can be removed to avoid the performance issues?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. I confirmed the issue, and opened #2496.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants