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

Fix frame header CC tests #1550

Merged
merged 5 commits into from
Aug 22, 2024

Conversation

lpawelcz
Copy link
Contributor

Fixes #1547

CC @proppy

This PR fixes the handling of absl:Span with test data input vectors for the frame_header tests.
It looks like we must copy the vectors over to the ZSTDFrameHeader struct and keep those there for the time of the test case execution and use absl::Span based on those copies.
Without this modification we observed that few of the test cases will always fail due to incorrect data under the input_buffer span. The interesting thing is that when we commented out all test cases except one of the failing ones (e.g. FrameHeaderTest.Success) we noticed that this particular test case started passing indicating that the issue can be triggered by execution of multiple test cases at the same time.

This PR also fixes some formatting errors that were picked up with clang-format version 18.1.8

Signed-off-by: Pawel Czarnecki <pczarnecki@antmicro.com>
Signed-off-by: Pawel Czarnecki <pczarnecki@antmicro.com>
ZSTD_frameHeader kHeader;
size_t kResult;

absl::Span<const uint8_t> kBuffer() const {
Copy link
Collaborator

Choose a reason for hiding this comment

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

google style is just buffer() since the member is buffer_

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed from kBuffer() to buffer()

return absl::MakeConstSpan(buffer_);
}

ZstdFrameHeader(absl::Span<const uint8_t> buffer, ZSTD_frameHeader& h,
Copy link
Collaborator

Choose a reason for hiding this comment

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

google style says since it has a constructor it should be a class and not a struct

also passing mutable references is less preferrable here than passing by value -- for any large type (which the frameHeader may be) you can std::move the value

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed ZstdFrameHeader to class and dropped passing by reference in favor of passing by value + std::move

@@ -113,7 +126,7 @@ class FrameHeaderTest : public xls::IrTestBase {
// expected values.
void RunAndExpectFrameHeader(const ZstdFrameHeader& zstd_frame_header) {
// Extend buffer contents to 128 bits if necessary.
const absl::Span<const uint8_t>& buffer = zstd_frame_header.kBuffer;
const absl::Span<const uint8_t>& buffer = zstd_frame_header.kBuffer();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't take refs to spans, spans are easily copied so we pass them and hold them by value

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

@@ -213,8 +213,6 @@ cc_test(
tags = ["manual"],
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason why this test is marked "manual" ? Given that this was hiding an issue, it is probably good to have that enabled.
(Only if it is taking too many resources I'd consider it tagging manual. But then with a comment as explanation)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We marked all DSLX and C++ tests as manual so that those would be called only in the separate ZSTD-specific CI workflow. It explicitly calls all of those rules tagged as manual and the workflow is triggered when there is a PR that changes the xls/modules/zstd directory or there is a push to main branch that changes it.

This was first requested in #1315 (comment).
After that we also decided to tag some of the build rules as manual because e.g. place_and_route rule is time consuming and it makes sense to not run it in every CI run (see #1315 (comment)).

Copy link
Member

Choose a reason for hiding this comment

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

@proppy do the reasons for manually running tests still hold ? I think it is more a danger to not run tests all the time, because then hidden issues will go undetected.

Copy link
Member

Choose a reason for hiding this comment

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

@hzeller the initial reason was that there were wip tests capturing current limitations of the implementation, but I don't believe that's the case anymore is it @lpawelcz ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@proppy Note you can disable them in gtest by calling them TEST(MyTest, DISABLED_DoStuffThatOnlyCompilesButFailAtRuntime) { ... }

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hzeller the initial reason was that there were wip tests capturing current limitations of the implementation, but I don't believe that's the case anymore is it @lpawelcz ?

Yes, that was the initial reason that no longer holds.
There is also a second reason which is the length of the CI workflow. We wanted to avoid running all of our tests each time because both the C++ tests and the benchmarks (build rules for synthesis, place and route; run rules for IR benchmarks) are very time consuming.

With the suggestion from @cdleary I removed the manual tags for the C++ tests so that at least those will be executed in the main CI workflow.

@hzeller
Copy link
Member

hzeller commented Aug 19, 2024

Can you also run

bant dwyu //xls/modules/...

? Looks like there is an unnecessary @com_google_absl//absl/status dependency in //xls/modules/zstd:data_generator

@lpawelcz lpawelcz force-pushed the 64294-fix-frame-header-tests branch from f404d7d to 63d72db Compare August 20, 2024 08:06
@lpawelcz
Copy link
Contributor Author

Can you also run

bant dwyu //xls/modules/...

? Looks like there is an unnecessary @com_google_absl//absl/status dependency in //xls/modules/zstd:data_generator

I checked the code with bant (current main at hzeller/bant@d033e1a) and it doesn't report anything.

Copy link
Collaborator

@cdleary cdleary left a comment

Choose a reason for hiding this comment

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

Looks good with the member changes.

Would be good to not mark the c++ tests as manual just the backend targets if possible.

struct ZstdFrameHeader {
absl::Span<const uint8_t> kBuffer;
class ZstdFrameHeader {
public:
ZSTD_frameHeader kHeader;
size_t kResult;
Copy link
Collaborator

Choose a reason for hiding this comment

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

These members should be private with accessors and shouldn't be named kSomething because they're not constexpr.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

@hzeller
Copy link
Member

hzeller commented Aug 20, 2024

I checked the code with bant (current main at hzeller/bant@d033e1a) and it doesn't report anything.

@lpawelcz

Interesting. Since off-topic here, can you open a bug in bant, reference this PR and show what you see as output of

# -vvv for extra verbose explaining what it is doing internally
bant dwyu -vvv //xls/modules/zstd:data_generator

I do get a

buildozer 'remove deps @com_google_absl//absl/status' //xls/modules/zstd:data_generator

because there is no absl/status/status.h included (grep status.h xls/modules/zstd/data_generator.{h,cc}) in any of the source files.

Internal-tag: [#64294]
Signed-off-by: Pawel Czarnecki <pczarnecki@antmicro.com>
Internal-tag: [#64294]
Signed-off-by: Pawel Czarnecki <pczarnecki@antmicro.com>
Internal-tag: [#64294]
Signed-off-by: Pawel Czarnecki <pczarnecki@antmicro.com>
@lpawelcz
Copy link
Contributor Author

I checked the code with bant (current main at hzeller/bant@d033e1a) and it doesn't report anything.

@lpawelcz

Interesting. Since off-topic here, can you open a bug in bant, reference this PR and show what you see as output of

# -vvv for extra verbose explaining what it is doing internally
bant dwyu -vvv //xls/modules/zstd:data_generator

I do get a

buildozer 'remove deps @com_google_absl//absl/status' //xls/modules/zstd:data_generator

because there is no absl/status/status.h included (grep status.h xls/modules/zstd/data_generator.{h,cc}) in any of the source files.

This was error on my side when using bant. Now I was able to get the correct output. I removed the unnecessary dependency from the BUILD file.

@copybara-service copybara-service bot merged commit f083652 into google:main Aug 22, 2024
5 checks passed
@lpawelcz lpawelcz deleted the 64294-fix-frame-header-tests branch August 22, 2024 06:51
@lpawelcz lpawelcz restored the 64294-fix-frame-header-tests branch August 22, 2024 10:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

//xls/modules/zstd:frame_header_cc_test is failing at HEAD
4 participants