Add ETPRIsize_t support to ExecuTorch for Xtensa #7895
Merged
Conversation
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
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/7895
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 1b92ed9 with merge base 71c0ad8 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68131252 |
Contributor
Author
|
@pytorchbot label "topic: not user facing" |
dbort
approved these changes
Jan 23, 2025
cmt0
force-pushed
the
export-D68131252
branch
from
8aa5eec to
036ca20
Compare
cmt0
added a commit
to cmt0/executorch
that referenced
this pull request
Jan 28, 2025
Summary: topic: not user facing Our Xtensa G3's toolchain, which is as recent as RJ-2024.3 release doesn't have %zu format specifier support. Since we only have the precompiled libc.a provided from cadence -- it seems from the disassembly that only the following are supported %c: character %s: string %d: decimal integer %i: decimal integer (same as %d) %u: unsigned decimal integer %x: hexadecimal integer %X: uppercase hexadecimal integer %p: pointer which is consistent with what I've seen come-out from ET_LOG prints that pass through the vsnprintf specifier Haven't heard of a 64-bit Xtensa DSP, so I think this 'lu' specifier mapping should work for all Xtensa toolchains regardless of vsnprintf implementation. This diff also updates a couple of places where I most commonly see the mishandled %zu specifier. If the changes are okay, I can more widely update print statements in ExecuTorch. It would touch a lot of files, some of which would never be compiled for Xtensa. Differential Revision: D68131252
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68131252 |
cmt0
added a commit
to cmt0/executorch
that referenced
this pull request
Jan 28, 2025
Summary: topic: not user facing Our Xtensa G3's toolchain, which is as recent as RJ-2024.3 release doesn't have %zu format specifier support. Since we only have the precompiled libc.a provided from cadence -- it seems from the disassembly that only the following are supported %c: character %s: string %d: decimal integer %i: decimal integer (same as %d) %u: unsigned decimal integer %x: hexadecimal integer %X: uppercase hexadecimal integer %p: pointer which is consistent with what I've seen come-out from ET_LOG prints that pass through the vsnprintf specifier Haven't heard of a 64-bit Xtensa DSP, so I think this 'lu' specifier mapping should work for all Xtensa toolchains regardless of vsnprintf implementation. This diff also updates a couple of places where I most commonly see the mishandled %zu specifier. If the changes are okay, I can more widely update print statements in ExecuTorch. It would touch a lot of files, some of which would never be compiled for Xtensa. Differential Revision: D68131252
cmt0
force-pushed
the
export-D68131252
branch
from
036ca20 to
0ca181e
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68131252 |
Summary: topic: not user facing Our Xtensa G3's toolchain, which is as recent as RJ-2024.3 release doesn't have %zu format specifier support. Since we only have the precompiled libc.a provided from cadence -- it seems from the disassembly that only the following are supported %c: character %s: string %d: decimal integer %i: decimal integer (same as %d) %u: unsigned decimal integer %x: hexadecimal integer %X: uppercase hexadecimal integer %p: pointer which is consistent with what I've seen come-out from ET_LOG prints that pass through the vsnprintf specifier Haven't heard of a 64-bit Xtensa DSP, so I think this 'lu' specifier mapping should work for all Xtensa toolchains regardless of vsnprintf implementation. This diff also updates a couple of places where I most commonly see the mishandled %zu specifier. If the changes are okay, I can more widely update print statements in ExecuTorch. It would touch a lot of files, some of which would never be compiled for Xtensa. Differential Revision: D68131252
cmt0
force-pushed
the
export-D68131252
branch
from
7e103f0 to
1b92ed9
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D68131252 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary:
Our Xtensa G3's toolchain, which is as recent as RJ-2024.3 release doesn't have %zu format specifier support. Since we only have the precompiled libc.a provided from cadence -- it seems from the disassembly that only the following are supported
%c: character
%s: string
%d: decimal integer
%i: decimal integer (same as %d)
%u: unsigned decimal integer
%x: hexadecimal integer
%X: uppercase hexadecimal integer
%p: pointer
which is consistent with what I've seen come-out from ET_LOG prints that pass through the vsnprintf specifier
Haven't heard of a 64-bit Xtensa DSP, so I think this 'lu' specifier mapping should work for all Xtensa toolchains regardless of vsnprintf implementation.
This diff also updates a couple of places where I most commonly see the mishandled %zu specifier. If the changes are okay, I can more widely update print statements in ExecuTorch. It would touch a lot of files, some of which would never be compiled for Xtensa.
Differential Revision: D68131252