This is an archive of the discontinued LLVM Phabricator instance.

[XRay] Implement powerpc64le xray.
ClosedPublic

Authored by timshen on Feb 8 2017, 6:02 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

timshen created this revision.Feb 8 2017, 6:02 PM
dberris requested changes to this revision.Feb 9 2017, 12:43 AM
dberris added inline comments.
compiler-rt/lib/xray/xray_powerpc64.cc
34 ↗(On Diff #87741)

Just curious -- does ppc not have an equivalent for rdtscp instruction in userspace?

If it does, we should try and use that as well as get the actual cycle frequency in Linux through the various possible means.

50–52 ↗(On Diff #87741)

Can we do this check once somewhere at the top of the file? Something like:

#if !defined(__LITTLE_ENDIAN__)
#error ...
#endif
compiler-rt/lib/xray/xray_utils.cc
175 ↗(On Diff #87741)

As far as I can tell, we don't build XRay for Mac OS (unless this is being done for other reasons). Will this work just fine without #if defined(__APPLE__) here?

This revision now requires changes to proceed.Feb 9 2017, 12:43 AM
timshen updated this revision to Diff 87780.Feb 9 2017, 2:51 AM
timshen edited edge metadata.

Update on comments.

timshen marked an inline comment as done.Feb 9 2017, 2:52 AM
timshen added inline comments.
compiler-rt/lib/xray/xray_powerpc64.cc
34 ↗(On Diff #87741)

It's a good question.

It turns out, Power CPU keeps track of the ticks as well as x86 does, but in a different frequency, not necessarily the CPU clock frequency. The frequency is configurable.

Luckily, glibc exposes two functions to get the frequency as well as the current tick: https://www.gnu.org/software/libc/manual/html_node/PowerPC.html. I think this is exactly what we need.

However, currently the xray_utils.h interfaces are designed in a way to assume the TSC frequency is the same as CPU clock frequency, and every logging module is asking for CPU frequency.

I think a more proper change is to generalize CPU frequency to a "timer frequency" or something, but I'd better do that in a succeeding patch, leaving this patch a bit cleaner. I can check in the frequency change first.

compiler-rt/lib/xray/xray_utils.cc
175 ↗(On Diff #87741)

Done. I realized that compiler_rt, as well as libgcc, has this __clear_cache function, but they seem to do poorly on the job. I moved the clearCache function into xray_powerpc64.cc and kept powerpc64 case only.

timshen updated this revision to Diff 87781.Feb 9 2017, 2:56 AM

Use emulated TSC for now.

timshen updated this revision to Diff 87871.Feb 9 2017, 1:46 PM

Use emulated TSC until the frequency interface design is clear.

timshen updated this revision to Diff 87909.Feb 9 2017, 4:25 PM

Rebase onto D29796.

dberris accepted this revision.Feb 9 2017, 4:42 PM

I defer to @echristo on the ppc-specific bits. I suspect you want to stage committing this by doing the LLVM side changes first, and the clang changes next, then finally the compiler-rt implementation.

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
1136 ↗(On Diff #87909)

Probably want a friendly/informative message saying why this ought to be unreachable -- does the codegen not disambiguate tail calls and patchable returns?

This revision is now accepted and ready to land.Feb 9 2017, 4:42 PM
echristo accepted this revision.Feb 9 2017, 4:50 PM

Rough request for more elaborate comments and a couple of inline comments, but nothing major. Feel free to commit after.

Thanks!

-eric

llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
1136 ↗(On Diff #87909)

+1

llvm/lib/Target/PowerPC/PPCInstrInfo.cpp
68 ↗(On Diff #87909)

-1? Can you make this a bit more descriptive? :)

timshen updated this revision to Diff 88041.Feb 10 2017, 12:50 PM

Updated as commented.

timshen marked an inline comment as done.Feb 10 2017, 12:52 PM
timshen added inline comments.
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
1136 ↗(On Diff #87909)

Sorry, I didn't mean to leave it empty... sometimes when I turn a poc into a real patch I miss things. :P

llvm/lib/Target/PowerPC/PPCInstrInfo.cpp
68 ↗(On Diff #87909)

Added a block comment indicating the parameter. It's default-initialized to -1 if I don't manually initialize it. I have to, however, manually initialize it, because of our lovely C++ default-argument rules.

This revision was automatically updated to reflect the committed changes.
timshen marked an inline comment as done.
This revision is now accepted and ready to land.Feb 11 2017, 4:49 AM
This revision was automatically updated to reflect the committed changes.
timshen reopened this revision.Feb 15 2017, 1:22 PM

This patch gets reverted, because the sanitizer-ppc64le bots aren't happy about:

http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux/builds/1414/steps/test%20standalone%20compiler-rt/logs/stdio

kbarton@ can you take a look?

This revision is now accepted and ready to land.Feb 15 2017, 1:22 PM

Dean found out that we actually compare different types (std::errc against std::error_code) in the tests, and the implicit std::errc -> std::error_code may never happen. Checked in r295248 to fix that. Landing the xray patch again to see how the bots react. :P

This revision was automatically updated to reflect the committed changes.