-
Notifications
You must be signed in to change notification settings - Fork 15.4k
[libclc] Skip opt command if opt_flags is empty #130882
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
Closed
Closed
Changes from 4 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
1727cb4
[libclc] Skip opt command if opt_flags is empty
wenju-he d3543f3
unconditionally add builtins_opt_lib_tgt, which is empty if OPT_FLAGS…
wenju-he e02feed
update comment
wenju-he cb61d08
refine
wenju-he e7cecc2
unify PROPERTIES FOLDER
wenju-he 36ea924
NOT ARG_OPT_FLAGS
wenju-he File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realised this code isn't triggered upstream. I take it you have a downstream making use of it?
I tried it locally and this needs to be
if( "${ARG_OPT_FLAGS} STREQUAL "" )or maybe better yetif ( NOT ARG_OPT_FLAGS ). The code as-is generates an error if I pass in an empty OPT_FLAGS:Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a case in upstream LLVM that opt flag is empty:
llvm-project/libclc/CMakeLists.txt
Line 353 in ad5cac3
Thanks for the testing. Changed to
if ( NOT ARG_OPT_FLAGS )I don't know what happened, a few days ago I did observe that bitcode size become smaller or larger when opt flag is empty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remembered. I was testing for amdgpu arch. I just switched the code between if and else blocks for testing, and didn't set opt_flags to empty. So the check was wrong at the beginning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true about SPIR-V, but those targets exit early before we reach the opt target.
If there's no plan for this code to be used in production, I'm not sure it's worth adding this extra logic which needs to be maintained. If it's just for being played around with in testing then the extra time it takes to build isn't so bad? Unless I'm misunderstanding the problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just curious would this Pr unifies the this code and avoid the early exit and duplicate code for prepare target?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let me know if it worth to update PR to unifies the code path and avoids early exit. Otherwise I'll close this PR.
The original request of this PR is to disable opt -O3. But things has changed and the request is irrelevant.
Though in practice it might still make sense to apply the PR to avoid code diverge like for SPIR-V.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that might be good actually. Then if SPIR-V did ever want to apply optimizations, it could do so, and it ensures this path is tested.
Note though we'd still need the special-case after the opt target, because SPIR-V will continue to want to run
llvm-spirvand exit. It also doesn't run the${prepare_builtins_exe}utility so needs to exit before that point. I don't know enough aboutprepare-builtinsto say whether SPIR-V could also make use of it: it seems to stripopencl.ocl.versionmetadata and set every external definition tolinkonce_odrlinkage. I'd need to investigate what's going on there.