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.

Sign up for GitHub

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

Jump to bottom

Use dedicated string attribute for string literals #374

Open
Lancern opened this issue Dec 30, 2023 · 0 comments
Open

Use dedicated string attribute for string literals #374

Lancern opened this issue Dec 30, 2023 · 0 comments

Comments

@Lancern
Copy link
Member

Lancern commented Dec 30, 2023 •
edited
Loading

Currently C/C++ string literals are lowered to a #cir.const_array with a built-in mlir::StringAttr that holds the constant string value. However, the built-in mlir::StringAttr does not hold the character set of the string literal (i.e. only char strings and char8_t strings are supported now).

We can introduce a new attribute #cir.string that holds the string literal value together with its character set information (char and char8_t, wchar_t, char16_t, char32_t). Based on the new attribute we can support wide string literals (wchar_t string), UTF-16 string literals (char16_t string), and UTF-32 string literals (char32_t string).

I'd love to help draft a PR for this if this is necessary.
@Lancern Lancern mentioned this issue Jan 13, 2024
Merged
bcardosolopes pushed a commit that referenced this issue Jan 19, 2024
@Lancern
[CIR][CIRGen] Support wide string literals (#399)
b42f884 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in #374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in #374 may not be that helpful as I
thought.
lanza pushed a commit that referenced this issue Jan 29, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (#399)
64d546a 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in #374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in #374 may not be that helpful as I
thought.
lanza pushed a commit that referenced this issue Mar 23, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (#399)
377c348 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in #374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in #374 may not be that helpful as I
thought.
eZWALT pushed a commit to eZWALT/clangir that referenced this issue Mar 24, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (llvm#399)
64efeb2 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in llvm#374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in llvm#374 may not be that helpful as I
thought.
eZWALT pushed a commit to eZWALT/clangir that referenced this issue Mar 24, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (llvm#399)
aac54a7 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in llvm#374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in llvm#374 may not be that helpful as I
thought.
lanza pushed a commit that referenced this issue Apr 29, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (#399)
c720fac 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in #374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in #374 may not be that helpful as I
thought.
lanza pushed a commit that referenced this issue Apr 29, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (#399)
83b9b0f 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in #374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in #374 may not be that helpful as I
thought.
eZWALT pushed a commit to eZWALT/clangir that referenced this issue Apr 29, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (llvm#399)
b254b47 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in llvm#374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in llvm#374 may not be that helpful as I
thought.
lanza pushed a commit that referenced this issue Apr 29, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (#399)
7a4e5c3 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in #374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in #374 may not be that helpful as I
thought.
bruteforceboy pushed a commit to bruteforceboy/clangir that referenced this issue Oct 2, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (llvm#399)
70139e4 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in llvm#374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in llvm#374 may not be that helpful as I
thought.
Hugobros3 pushed a commit to shady-gang/clangir that referenced this issue Oct 2, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (llvm#399)
d0f7f56 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in llvm#374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in llvm#374 may not be that helpful as I
thought.
keryell pushed a commit to keryell/clangir that referenced this issue Oct 19, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (llvm#399)
b83ad3d 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in llvm#374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in llvm#374 may not be that helpful as I
thought.
lanza pushed a commit that referenced this issue Nov 5, 2024
@Lancern @lanza
[CIR][CIRGen] Support wide string literals (#399)
a11dc1d 
This commit supports the codegen of wide string literals, including
`wchar_t` string literals, `char16_t` string literals, and `char32_t`
string literals.

I'm not following the proposal in #374. The clang frontend doesn't
record the literal string. It only records the encoded code units for
wide string literals. So I believe that a dedicated string attribute
with an encoding tag as described in #374 may not be that helpful as I
thought.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Lancern