This is an archive of the discontinued LLVM Phabricator instance.

[XRay] [compiler-rt] Simplify FDR logging handler. [NFC]
ClosedPublic

Authored by pelikan on Apr 11 2017, 12:44 AM.

Details

Summary

Not repeating screamy failure paths makes the 300+ line function a bit shorter.
There's no need to overload the variable name "Buffer" if it only works on the
thread local buffer. Fix some comments while there.

I plan to move the rewinding logic into a separate function too, but in this
diff it would be too much of a mess to comprehend. This is trivially NFC.

Diff Detail

Repository
rL LLVM

Event Timeline

pelikan created this revision.Apr 11 2017, 12:44 AM
dberris edited edge metadata.Apr 11 2017, 12:49 AM

LGTM

Just FYI: I and @kpw thought the current state would be a good compromise to being able to start writing more granular unit tests. I think we can think about alternative ways of doing testing involving more end-to-end tests now that we can do FDR tests with the lit infrastructure, so the original motivation for this is no longer as important.

Ack. I don't mean this from the "easy to test" perspective. I want the code to be easier to read. I don't mind tall functions as long as they're simple, and this one has quite a lot of detail on several (distinct) topics. It deals with both types of entries, TSCs, rewinding, buffer shortages and tail call handling all at once. It's not very pleasant for me to keep scrolling such a large amount of code on the screen, that's all.

Motivation for what exactly is no longer as important?

Finer grained testing (unit-testing individual / combinations of internal implementations) isn't as important now compared to doing end-to-end testing. So while the status quo allows us to test the individual functions (i.e. passing a buffer queue that wasn't the thread-local buffer queue), your change makes it harder to test in a controlled environment.

I'm saying that since we don't need to actually have finer grained testing because we can do it with end-to-end testing, this change should be fine.

kpw accepted this revision.Apr 11 2017, 5:03 PM

I think we'll probably want to explore tests with very specific call sequences in the future, and that's why the Buffer was passed around.

No point in over constraining what we have now for a nebulous future though. LGTM.

This revision is now accepted and ready to land.Apr 11 2017, 5:03 PM
This revision was automatically updated to reflect the committed changes.