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

[CI] Do not enable assertions by default in configure.py script #17616

Closed
wants to merge 1 commit into from

Conversation

uditagarwal97
Copy link
Contributor

@uditagarwal97 uditagarwal97 commented Mar 24, 2025

In release build, upstream LLVM require users to explicitly specify LLVM_ENABLE_ASSERTIONS to build with assertions. However, in configure.py script, we do the opposite: we enable assertions by default and ask users to specify --no-assertions to disable them.
This PR aligns configure.py script with the upstream.

@uditagarwal97 uditagarwal97 self-assigned this Mar 24, 2025
@uditagarwal97 uditagarwal97 marked this pull request as ready for review March 24, 2025 18:17
@uditagarwal97 uditagarwal97 requested a review from a team as a code owner March 24, 2025 18:17
@@ -113,7 +113,7 @@ jobs:
uses: ./.github/workflows/sycl-windows-build.yml
with:
compiler: icx
build_configure_extra_args: -DCMAKE_C_FLAGS="/fp:precise /clang:-Wno-nonportable-include-path /clang:-Wno-cast-function-type-mismatch" -DCMAKE_CXX_FLAGS="/fp:precise /clang:-Wno-nonportable-include-path /clang:-Wno-cast-function-type-mismatch" -DCMAKE_EXE_LINKER_FLAGS=/manifest:no -DCMAKE_MODULE_LINKER_FLAGS=/manifest:no -DCMAKE_SHARED_LINKER_FLAGS=/manifest:no
build_configure_extra_args: --enable-assertions -DCMAKE_C_FLAGS="/fp:precise /clang:-Wno-nonportable-include-path /clang:-Wno-cast-function-type-mismatch" -DCMAKE_CXX_FLAGS="/fp:precise /clang:-Wno-nonportable-include-path /clang:-Wno-cast-function-type-mismatch" -DCMAKE_EXE_LINKER_FLAGS=/manifest:no -DCMAKE_MODULE_LINKER_FLAGS=/manifest:no -DCMAKE_SHARED_LINKER_FLAGS=/manifest:no
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note: We enable assertions when testing on windows in pre, post-commit and nightly. For more coverage, we should disable assertions in post-commit - that's what we also do for Linux.

@@ -45,6 +45,7 @@ jobs:
build_cache_root: "/__w/"
build_artifact_suffix: "default"
build_cache_suffix: "default"
build_configure_extra_args: --enable-assertions
Copy link
Contributor

Choose a reason for hiding this comment

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

how about we put this in the ci-defaults section of the configure.py script instead of yaml?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should this be a default in the CI? IIUC, for Linux, we enable assertions only in Nightly and pre-commit, but not during post-commit.

Copy link
Contributor

Choose a reason for hiding this comment

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

ah okay i see, yeah i guess lets not change it now

@@ -38,7 +38,7 @@ jobs:
with:
build_cache_root: "/__w/"
build_artifact_suffix: default
build_configure_extra_args: '--hip --cuda'
build_configure_extra_args: '--enable-assertions --hip --cuda'
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@KornevNikita I'll create a followup PR to disable assertions in release branch.

Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

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

In release build, upstream LLVM require users to explicitly specify LLVM_ENABLE_ASSERTIONS to build with assertions.

What do mean by "LLVM release build"?

However, in configure.py script, we do the opposite: we enable assertions by default and ask users to specify --no-assertions to disable them.
This PR aligns configure.py script with the upstream.

I don't understand the motivation for that change. "aligning with the upstream" has no sense because configure.py is our own script, which has nothing to do with the upstream.

The script defaults are configured for SYCL development environment, which better enable assertions by default.

Please, provide justification for this change other than aligning with the upstream.

@uditagarwal97
Copy link
Contributor Author

In release build, upstream LLVM require users to explicitly specify LLVM_ENABLE_ASSERTIONS to build with assertions.

What do mean by "LLVM release build"?

However, in configure.py script, we do the opposite: we enable assertions by default and ask users to specify --no-assertions to disable them.
This PR aligns configure.py script with the upstream.

I don't understand the motivation for that change. "aligning with the upstream" has no sense because configure.py is our own script, which has nothing to do with the upstream.

The script defaults are configured for SYCL development environment, which better enable assertions by default.

Please, provide justification for this change other than aligning with the upstream.

Hi Alexey,

Thanks for sharing your concern. Yes, configure.py is our own script but when I say "aligning with the upstream", I meant alignment in terms of the developer expectation. With the upstream, developer expectation is that assertions won't be enabled unless I explicitly specify LLVM_ENABLE_ASSERTIONS, but with configure.py script, we implicitly enable assertions.

The script defaults are configured for SYCL development environment, which better enable assertions by default.

A better question would be: why do you think we should enable assertions by default for all SYCL developers?
Not sure about others, I, for one, find it very counter intuitive to have assertions enabled by default.

@bader
Copy link
Contributor

bader commented Mar 25, 2025

A better question would be: why do you think we should enable assertions by default for all SYCL developers?
Not sure about others, I, for one, find it very counter intuitive to have assertions enabled by default.

Assertions is heavily used by SYCL and LLVM projects to detect errors. As I mentioned in the previous comment LLVM recommends enabling assertions for development.

There are cases when assertions should be disabled to avoid an overhead added by the assertion checks, but most of SYCL developers should have assertions enabled. That's why configure.py enables assertions by default.

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.

None yet

3 participants