This is an archive of the discontinued LLVM Phabricator instance.

[libc] Specialize portion of hypot for x86_64 CPUs.
AbandonedPublic

Authored by cratonica on Jan 18 2022, 10:34 AM.

Details

Reviewers
lntue
sivachandra
Summary

This changes leverages the BSR instruction to find the leading 1 bit, reducing
what was previously an iterative look-up-table approach to a single
instruction on supported CPUs.

Diff Detail

Event Timeline

cratonica created this revision.Jan 18 2022, 10:34 AM
cratonica requested review of this revision.Jan 18 2022, 10:34 AM
lntue added inline comments.
libc/src/__support/find_leading_one.h
26

Is the BSR instruction available for x86 also? If so then I think LLVM_LIBC_ARCH_X86 should be better. And if that's the case, you can just leave the implementation in the x86_64 folder, I don't think we need separate folders for x86 and x86-64.

cratonica added inline comments.Jan 18 2022, 11:38 AM
libc/src/__support/find_leading_one.h
26

My understanding is that we'd be limited to 32-bit operands in that case and would therefore need to make this conditional upon both the size of the data and the architecture, which might be messier (so, x86 would drop back to the generic implementation for 64-bit numbers, or I suppose I could implement it as two BSR calls if it's possible to test this in 32-bit mode).

Happy to do whatever you think is best.

lntue accepted this revision.Jan 18 2022, 11:56 AM
lntue added inline comments.
libc/src/__support/find_leading_one.h
26

If that's the case then I'm fine with the current specialization. We can always specialize further if there are requests for non-64-bit x86 arch.

This revision is now accepted and ready to land.Jan 18 2022, 11:56 AM
cratonica marked an inline comment as done.Jan 18 2022, 1:38 PM
sivachandra added inline comments.Jan 18 2022, 2:04 PM
libc/src/__support/x86_64/find_leading_one.h
20

Nit: msbit_pos is probably a more appropriate name?

28–31

It seems to me like one can use __builtin_clz and avoid target assembly? For example: https://godbolt.org/z/eY8n8P118

cratonica added inline comments.Jan 18 2022, 2:15 PM
libc/src/__support/x86_64/find_leading_one.h
28–31

Nice, that also works for ARM: https://godbolt.org/z/bY9nfEd16

Are we OK using such builtins in this library ? If so, should we get rid of the original find_leading_one() function altogether and just call __builtin_clz ? Or should it still be specialized for each architecture and delegate at that level?

sivachandra added inline comments.Jan 18 2022, 2:24 PM
libc/src/__support/x86_64/find_leading_one.h
28–31

Yes, it is OK to use compiler builtins for this use case. We can get rid of the original find_leading_one.

cratonica added inline comments.Jan 19 2022, 8:13 AM
libc/src/__support/x86_64/find_leading_one.h
28–31
lntue added inline comments.Jan 19 2022, 8:31 AM
libc/src/__support/x86_64/find_leading_one.h
28–31

Normally you could just amend the commit and update the patch review with $ arc diff --update D.... instead of creating a new one, unless you want to keep the old review around.

cratonica added inline comments.Jan 19 2022, 8:40 AM
libc/src/__support/x86_64/find_leading_one.h
28–31

I'd like to hang onto it for a few reasons:

  • This approach is much different, so I wanted to require you to approve it again rather than sneaking in an entirely new approach under the radar
    • The diff between revisions would be messy, since the new code is much closer to HEAD than it is to where this branch (all new unit tests and the refactor to its own library would be deleted)
    • I'd like to be able to reference the original revision in the future.

That being said, I don't want to deviate from the norms used by LLVM, so I can amend it here if you'd prefer.

lntue added inline comments.Jan 19 2022, 8:58 AM
libc/src/__support/x86_64/find_leading_one.h
28–31

It's totally fine to me to have the a separate review patch, especially when you want to refer back to the original one in the future. Just a few comments about how Phabricator works as I know of:

  • If there is any update to the patch, I'd need to re-approve again (you will see that any accepted tick next reviewers will be changed from green to gray)
  • If you amend the commit, Phabricator will show the diff between the latest change and HEAD by default. But it still records all of your previous revisions (each time you run arc diff --update), and we can selectively diff between them if we want to.
  • But yes, the default workflow from LLVM is a bit different from normal git workflow, where they prefer to have a single commit for each patch, and having their code review tools revolve around that.