Skip to content

Conversation

@thewilsonator
Copy link
Contributor

Also allows to add overloads of intrinsics without updating intrinsic_op, this supersedes #7995 as a more elegant solution to the dmd part of the fix for 18559.

it should also be faster on account of not computing the mangle, using Identifier comparisons and early exits.

Also allows to add overloads of intrinsics without updating intrinsic_op
@dlang-bot
Copy link
Contributor

Thanks for your pull request and interest in making D better, @thewilsonator! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

  • My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
  • My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
  • I have provided a detailed rationale explaining my changes
  • New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.


If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

@ibuclaw
Copy link
Member

ibuclaw commented Mar 11, 2018

Well, not testing the mangle deco is no good, as not all overrides are intrinsics.

I'm not sure if this is faster, now you have linear search, rather than ... for some reason I thought you were using binary search for matching intrinsics in your front-end.

if (id3 == Id.outpw) op = OPoutp;

if (id3 == Id.bswap) op = OPbswap;
if (id3 == Id._popcnt) op = OPpopcnt;
Copy link
Member

@ibuclaw ibuclaw Mar 11, 2018

Choose a reason for hiding this comment

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

It would be better to check the identifier length first before the pointer comparison.
i.e: (pseudo-code)

switch (id3.length)
{
  case 3:
    if (id3 == Id.bsf)
      op = OPbsf;
    else if (...)
      // ...
    break;
  // other cases...
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

true. Will do.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, LDC/GDC should be able to vectorise it pretty well without the switch as a masked gather , DMD obviously won't do that. Switching on the length requires loading it, its probably cold: I don't think it would buy all that much over the if chains because they are pretty short.

Copy link
Member

Choose a reason for hiding this comment

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

Well, there were once only half a dozen or so intrinsics in the past, that list has grown considerably since then, and it will only continue to grow.

@thewilsonator
Copy link
Contributor Author

thewilsonator commented Mar 11, 2018

Its faster because there is no need to touch strings, just pointer compares with identifiers.

Well, not testing the mangle deco is no good, as not all overrides are intrinsics.

What do you mean by that? I've been mostly looking at the core.math ones. The one (well three) special cases are bsf, bsr and va_start which are handled.

bt[rcs] are take size_t parameters so that shouldn't matter I can't really see anything else.

Any ideas why this is segfaulting?

id3 = fd.ident;
auto md = fd.getModule().md;
if (!md)
return op;
Copy link
Member

Choose a reason for hiding this comment

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

Regarding segfault, I'm going to make a guess here.

Try:

auto m = fd.getModule();
if (!m || !m.md)
  return op;

id2 = md.id;

if (md.packages.dim != 1)
return op;
Copy link
Member

Choose a reason for hiding this comment

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

md.packages could also be null here, e.g: for module object.

OutBuffer buf;
mangleToBuffer(m, &buf);
const s = buf.peekString();
if (!strcmp(s, "4core4stdc6stdarg"))
Copy link
Member

Choose a reason for hiding this comment

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

strcmp must die. use peekSlice which returns a string. See also https://digitalmars.com/d/archives/digitalmars/D/internals/DMD_Technical_Debt_470.html

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is just a relocation of existing code. I want to get this working first :)

src/dmd/toir.d Outdated
*/
int intrinsic_op(FuncDeclaration fd)
{
Identifier id1,id2,id3;
Copy link
Member

Choose a reason for hiding this comment

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

Move these declarations to where they are first set to a value.

Copy link
Member

Choose a reason for hiding this comment

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

Make 'em const, too.

for (size_t i = 0; i < std_namearray64.length - 1; i++)
Lmath:
if (id3 == Id.cos) op = OPcos;
if (id3 == Id.sin) op = OPsin;
Copy link
Member

Choose a reason for hiding this comment

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

else if

"5bitop4inplFNbNikZk",
"5bitop4inpwFNbNikZt",
"5bitop4outpFNbNikhZh",
"5bitop5bswapFNaNbNiNfkZk",
Copy link
Contributor Author

@thewilsonator thewilsonator Mar 12, 2018

Choose a reason for hiding this comment

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

Why is only the 32-bit bswap an intrinsic (for both 64 and 32 bit)?

@thewilsonator
Copy link
Contributor Author

Hmm, semaphore seems to fail on 32-bit on this line ( with T == long ? ).

@thewilsonator
Copy link
Contributor Author

I have no idea why this is not working on 32-bit, so in the interest of moving forward with 18559 please review #7995

@thewilsonator
Copy link
Contributor Author

rebased as #8942

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants