remove a const qualifier in a method's return type #12
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
Merged
liujisi
added a commit
that referenced
this pull request
Sep 4, 2014
remove a const qualifier in a method's return type
|
Hi huahang, please sign this Google Individual Contributor License Agreement: |
|
done |
|
Thanks very much. |
TeBoring
pushed a commit
to TeBoring/protobuf
that referenced
this pull request
Jan 19, 2019
Support maps in JSON parsing and serialization.
PierrickVoulet
pushed a commit
to PierrickVoulet/protobuf
that referenced
this pull request
Jun 6, 2020
Provide UT that reproduces issue protocolbuffers#10
copybara-service bot
pushed a commit
that referenced
this pull request
Oct 17, 2023
addresses #12714 by dumping more concise debug info for protobuf messages and repeated fields via the `serializeToJsonString` function. Additionally, message types which serialize into something other than an array (e.g. `Google\Protobuf\Value`, `Google\Protobuf\Timestamp`, etc) are handled in a special way to make their output consistent with other messages. ```php $m = new Google\Protobuf\DoubleValue(); $m->setValue(1.5); var_dump($m); ``` will output ``` object(Google\Protobuf\DoubleValue)#12 (1) { ["value"]=> float(1.5) } ``` Closes #12718 COPYBARA_INTEGRATE_REVIEW=#12718 from bshaffer:php-add-debuginfo c40a6f9 PiperOrigin-RevId: 574115431
copybara-service bot
pushed a commit
that referenced
this pull request
Dec 14, 2023
Masking a byte by 0xFF does nothing, and the optimizer can see that. I don't think these 0xFF masks do anything in java... but they're in a lot of places so if we remove them entirely it'll be in another CL. Before (android): ``` ldr w3, [x1, #12] and w4, w2, #0x7f orr w4, w4, #0x80 add w5, w3, #0x1 (1) sxtb w4, w4 ``` after: ``` ldr w3, [x1, #12] orr w4, w2, #0x80 add w5, w3, #0x1 (1) sxtb w4, w4 ``` PiperOrigin-RevId: 590766320
copybara-service bot
pushed a commit
that referenced
this pull request
Dec 14, 2023
Masking a byte by 0xFF does nothing, and the optimizer can see that. I don't think these 0xFF masks do anything in java... but they're in a lot of places so if we remove them entirely it'll be in another CL. Before (android): ``` ldr w3, [x1, #12] and w4, w2, #0x7f orr w4, w4, #0x80 add w5, w3, #0x1 (1) sxtb w4, w4 ``` after: ``` ldr w3, [x1, #12] orr w4, w2, #0x80 add w5, w3, #0x1 (1) sxtb w4, w4 ``` PiperOrigin-RevId: 590766320
copybara-service bot
pushed a commit
that referenced
this pull request
Dec 15, 2023
Masking a byte by 0xFF does nothing, and the optimizer can see that. I don't think these 0xFF masks do anything in java... but they're in a lot of places so if we remove them entirely it'll be in another CL. Before (android): ``` ldr w3, [x1, #12] and w4, w2, #0x7f orr w4, w4, #0x80 add w5, w3, #0x1 (1) sxtb w4, w4 ``` after: ``` ldr w3, [x1, #12] orr w4, w2, #0x80 add w5, w3, #0x1 (1) sxtb w4, w4 ``` PiperOrigin-RevId: 590766320
copybara-service bot
pushed a commit
that referenced
this pull request
Dec 15, 2023
Masking a byte by 0xFF does nothing, and the optimizer can see that. I don't think these 0xFF masks do anything in java... but they're in a lot of places so if we remove them entirely it'll be in another CL. Before (android): ``` ldr w3, [x1, #12] and w4, w2, #0x7f orr w4, w4, #0x80 add w5, w3, #0x1 (1) sxtb w4, w4 ``` after: ``` ldr w3, [x1, #12] orr w4, w2, #0x80 add w5, w3, #0x1 (1) sxtb w4, w4 ``` PiperOrigin-RevId: 591117756
GerHobbelt
pushed a commit
to GerHobbelt/protobuf
that referenced
this pull request
Aug 4, 2024
…otobufUpdate Marc9905/ft anno254 protobuf update
copybara-service bot
pushed a commit
that referenced
this pull request
Sep 11, 2024
This has twofold goals:
1. Correctness: if position overruns the array, checking space left may return a negative number. I'm not sure how bad that is, but let's avoid it.
2. Performance. This generates more optimal assembly code which can combine bounds checks, particularly on Android (I haven't looked at the generated assembly on the server JVM; it's possible the server JVM can already performance this hoist).
The `position` field is stored on the object, so Android ART generates assembly codes for `this.position++` like "load, add, store":
```
ldr w3, [x1, #12]
add w4, w3, #0x1 (1)
str w4, [x1, #12]
```
There can be a lot of these loads/stores executed each step of a loop (e.g. writeFixed64NoTag updates position 8 times, and varint encoding could do it even more). It's faster if we can hoist these so we load once at the start of the function, and store once at the end of the function. This also has the nice benefit that it won't store if we've thrown an exception.
See before/after in Compiler Explorer: https://godbolt.org/z/bWWYqsxK4. I'm not an assembly expert, but it seems clear that the increment instructions like `add w4, w0, #0x1 (1)` are no longer always surrounded by loads and stores in the new version.
And in Compiler Explorer, you also see `bufferFixed64NoTag` has reduced from 98 lines of assembly to 57 lines of assembly in the hoisted version. This is because we don't need to re-check the array bounds each time we reload `position`. I imagine this also makes any other method with a fixed number of increments like `writeFixed32NoTag` faster too.
PiperOrigin-RevId: 673588324
copybara-service bot
pushed a commit
that referenced
this pull request
Sep 25, 2024
When writing varints.
This has twofold goals:
1. Correctness: if position overruns the array, checking space left may return a negative number. I'm not sure how bad that is, but let's avoid it.
2. Performance. This generates more optimal assembly code which can combine bounds checks, particularly on Android (I haven't looked at the generated assembly on the server JVM; it's possible the server JVM can already performance this hoist).
The `position` field is stored on the object, so Android ART generates assembly codes for `this.position++` like "load, add, store":
```
ldr w3, [x1, #12]
add w4, w3, #0x1 (1)
str w4, [x1, #12]
```
There can be a lot of these loads/stores executed each step of a loop (e.g. writeFixed64NoTag updates position 8 times, and varint encoding could do it even more). It's faster if we can hoist these so we load once at the start of the function, and store once at the end of the function. This also has the nice benefit that it won't store if we've thrown an exception.
See before/after in Compiler Explorer: https://godbolt.org/z/bWWYqsxK4. I'm not an assembly expert, but it seems clear that the increment instructions like `add w4, w0, #0x1 (1)` are no longer always surrounded by loads and stores in the new version.
PiperOrigin-RevId: 678524739
copybara-service bot
pushed a commit
that referenced
this pull request
Oct 2, 2024
When writing varints.
This has twofold goals:
1. Correctness: if position overruns the array, checking space left may return a negative number. I'm not sure how bad that is, but let's avoid it.
2. Performance. This generates more optimal assembly code which can combine bounds checks, particularly on Android (I haven't looked at the generated assembly on the server JVM; it's possible the server JVM can already performance this hoist).
The `position` field is stored on the object, so Android ART generates assembly codes for `this.position++` like "load, add, store":
```
ldr w3, [x1, #12]
add w4, w3, #0x1 (1)
str w4, [x1, #12]
```
There can be a lot of these loads/stores executed each step of a loop (e.g. writeFixed64NoTag updates position 8 times, and varint encoding could do it even more). It's faster if we can hoist these so we load once at the start of the function, and store once at the end of the function. This also has the nice benefit that it won't store if we've thrown an exception.
See before/after in Compiler Explorer: https://godbolt.org/z/bWWYqsxK4. I'm not an assembly expert, but it seems clear that the increment instructions like `add w4, w0, #0x1 (1)` are no longer always surrounded by loads and stores in the new version.
PiperOrigin-RevId: 678524739
copybara-service bot
pushed a commit
that referenced
this pull request
Oct 3, 2024
When writing varints.
This has twofold goals:
1. Correctness: if position overruns the array, checking space left may return a negative number. I'm not sure how bad that is, but let's avoid it.
2. Performance. This generates more optimal assembly code which can combine bounds checks, particularly on Android (I haven't looked at the generated assembly on the server JVM; it's possible the server JVM can already performance this hoist).
The `position` field is stored on the object, so Android ART generates assembly codes for `this.position++` like "load, add, store":
```
ldr w3, [x1, #12]
add w4, w3, #0x1 (1)
str w4, [x1, #12]
```
There can be a lot of these loads/stores executed each step of a loop (e.g. writeFixed64NoTag updates position 8 times, and varint encoding could do it even more). It's faster if we can hoist these so we load once at the start of the function, and store once at the end of the function. This also has the nice benefit that it won't store if we've thrown an exception.
See before/after in Compiler Explorer: https://godbolt.org/z/bWWYqsxK4. I'm not an assembly expert, but it seems clear that the increment instructions like `add w4, w0, #0x1 (1)` are no longer always surrounded by loads and stores in the new version.
PiperOrigin-RevId: 681644516
copybara-service bot
pushed a commit
that referenced
this pull request
Oct 10, 2024
…um value is detected. This should never happen, so I don't think it matters much exactly what kind of exception we throw. We could even arguably return null, but this option saves a lot of space while still preserving some error checking. See https://godbolt.org/z/jKhcKs3x1 for code gen. This generates much tighter bytecode and ARM assembly than alternatives. As this code is generated many times over, small wins in code size here can reduce icache pressure, APK size, and OAT size. This java code: ```java Object uoe() { throw new UnsupportedOperationException(); } Object npe2() { throw null; } ``` Generates this dex code: ``` .method uoe()Ljava/lang/Object; new-instance v0, Ljava/lang/UnsupportedOperationException; invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V throw v0 .end method .method npe2()Ljava/lang/Object; const/4 v0, 0x0 throw v0 .end method ``` Which generates this OAT code: ``` java.lang.Object SomeProto.uoe() [84 bytes] 0x000081c0 sub x16, sp, #0x2000 (8192) 0x000081c4 ldr wzr, [x16] StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000081c8 str x0, [sp, #-48]! 0x000081cc str x22, [sp, #24] 0x000081d0 stp x23, lr, [sp, #32] 0x000081d4 ldr x21, [x21] StackMap[1] native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000081d8 mov x22, x1 0x000081dc adrp x0, #+0x4000 (addr 0x0000c000) 0x000081e0 ldr w0, [x0, #4] 0x000081e4 ldr lr, [tr, #464] ; pAllocObjectInitialized 0x000081e8 blr lr StackMap[2] native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b 0x000081ec dmb ishst 0x000081f0 mov x1, x0 0x000081f4 mov x23, x1 0x000081f8 adrp x0, #+0x4000 (addr 0x0000c000) 0x000081fc ldr w0, [x0, #12] 0x00008200 ldr lr, [x0, #24] 0x00008204 blr lr StackMap[3] native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b 0x00008208 mov x0, x23 0x0000820c ldr lr, [tr, #1264] ; pDeliverException 0x00008210 blr lr StackMap[4] native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b java.lang.Object SomeProto.npe2() [36 bytes] 0x000080d0 sub x16, sp, #0x2000 (8192) 0x000080d4 ldr wzr, [x16] StackMap[0] native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000080d8 str x0, [sp, #-32]! 0x000080dc stp x22, lr, [sp, #16] 0x000080e0 ldr x21, [x21] StackMap[1] native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000080e4 mov x22, x1 0x000080e8 mov w0, #0x0 0x000080ec ldr lr, [tr, #1264] ; pDeliverException 0x000080f0 blr lr StackMap[2] native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b ``` This saves 84-36 = 48 bytes of OAT per method. PiperOrigin-RevId: 684258075
copybara-service bot
pushed a commit
that referenced
this pull request
Oct 10, 2024
…um value is detected. This should never happen, so I don't think it matters much exactly what kind of exception we throw. We could even arguably return null, but this option saves a lot of space while still preserving some error checking. See https://godbolt.org/z/jKhcKs3x1 for code gen. This generates much tighter bytecode and ARM assembly than alternatives. As this code is generated many times over, small wins in code size here can reduce icache pressure, APK size, and OAT size. This java code: ```java Object uoe() { throw new UnsupportedOperationException(); } Object npe2() { throw null; } ``` Generates this dex code: ``` .method uoe()Ljava/lang/Object; new-instance v0, Ljava/lang/UnsupportedOperationException; invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V throw v0 .end method .method npe2()Ljava/lang/Object; const/4 v0, 0x0 throw v0 .end method ``` Which generates this OAT code: ``` java.lang.Object SomeProto.uoe() [84 bytes] 0x000081c0 sub x16, sp, #0x2000 (8192) 0x000081c4 ldr wzr, [x16] StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000081c8 str x0, [sp, #-48]! 0x000081cc str x22, [sp, #24] 0x000081d0 stp x23, lr, [sp, #32] 0x000081d4 ldr x21, [x21] StackMap[1] native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000081d8 mov x22, x1 0x000081dc adrp x0, #+0x4000 (addr 0x0000c000) 0x000081e0 ldr w0, [x0, #4] 0x000081e4 ldr lr, [tr, #464] ; pAllocObjectInitialized 0x000081e8 blr lr StackMap[2] native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b 0x000081ec dmb ishst 0x000081f0 mov x1, x0 0x000081f4 mov x23, x1 0x000081f8 adrp x0, #+0x4000 (addr 0x0000c000) 0x000081fc ldr w0, [x0, #12] 0x00008200 ldr lr, [x0, #24] 0x00008204 blr lr StackMap[3] native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b 0x00008208 mov x0, x23 0x0000820c ldr lr, [tr, #1264] ; pDeliverException 0x00008210 blr lr StackMap[4] native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b java.lang.Object SomeProto.npe2() [36 bytes] 0x000080d0 sub x16, sp, #0x2000 (8192) 0x000080d4 ldr wzr, [x16] StackMap[0] native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000080d8 str x0, [sp, #-32]! 0x000080dc stp x22, lr, [sp, #16] 0x000080e0 ldr x21, [x21] StackMap[1] native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000080e4 mov x22, x1 0x000080e8 mov w0, #0x0 0x000080ec ldr lr, [tr, #1264] ; pDeliverException 0x000080f0 blr lr StackMap[2] native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b ``` This saves 84-36 = 48 bytes of OAT per method. PiperOrigin-RevId: 684258075
copybara-service bot
pushed a commit
that referenced
this pull request
Oct 10, 2024
…um value is detected. This should never happen, so I don't think it matters much exactly what kind of exception we throw. We could even arguably return null, but this option saves a lot of space while still preserving some error checking. See https://godbolt.org/z/jKhcKs3x1 for code gen. This generates much tighter bytecode and ARM assembly than alternatives. As this code is generated many times over, small wins in code size here can reduce icache pressure, APK size, and OAT size. This java code: ```java Object uoe() { throw new UnsupportedOperationException(); } Object npe2() { throw null; } ``` Generates this dex code: ``` .method uoe()Ljava/lang/Object; new-instance v0, Ljava/lang/UnsupportedOperationException; invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V throw v0 .end method .method npe2()Ljava/lang/Object; const/4 v0, 0x0 throw v0 .end method ``` Which generates this OAT code: ``` java.lang.Object SomeProto.uoe() [84 bytes] 0x000081c0 sub x16, sp, #0x2000 (8192) 0x000081c4 ldr wzr, [x16] StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000081c8 str x0, [sp, #-48]! 0x000081cc str x22, [sp, #24] 0x000081d0 stp x23, lr, [sp, #32] 0x000081d4 ldr x21, [x21] StackMap[1] native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000081d8 mov x22, x1 0x000081dc adrp x0, #+0x4000 (addr 0x0000c000) 0x000081e0 ldr w0, [x0, #4] 0x000081e4 ldr lr, [tr, #464] ; pAllocObjectInitialized 0x000081e8 blr lr StackMap[2] native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b 0x000081ec dmb ishst 0x000081f0 mov x1, x0 0x000081f4 mov x23, x1 0x000081f8 adrp x0, #+0x4000 (addr 0x0000c000) 0x000081fc ldr w0, [x0, #12] 0x00008200 ldr lr, [x0, #24] 0x00008204 blr lr StackMap[3] native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b 0x00008208 mov x0, x23 0x0000820c ldr lr, [tr, #1264] ; pDeliverException 0x00008210 blr lr StackMap[4] native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b java.lang.Object SomeProto.npe2() [36 bytes] 0x000080d0 sub x16, sp, #0x2000 (8192) 0x000080d4 ldr wzr, [x16] StackMap[0] native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000080d8 str x0, [sp, #-32]! 0x000080dc stp x22, lr, [sp, #16] 0x000080e0 ldr x21, [x21] StackMap[1] native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000080e4 mov x22, x1 0x000080e8 mov w0, #0x0 0x000080ec ldr lr, [tr, #1264] ; pDeliverException 0x000080f0 blr lr StackMap[2] native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b ``` This saves 84-36 = 48 bytes of OAT per method. PiperOrigin-RevId: 684258075
copybara-service bot
pushed a commit
that referenced
this pull request
Oct 10, 2024
…um value is detected. This should never happen, so I don't think it matters much exactly what kind of exception we throw. We could even arguably return null, but this option saves a lot of space while still preserving some error checking. See https://godbolt.org/z/jKhcKs3x1 for code gen. This generates much tighter bytecode and ARM assembly than alternatives. As this code is generated many times over, small wins in code size here can reduce icache pressure, APK size, and OAT size. This java code: ```java Object uoe() { throw new UnsupportedOperationException(); } Object npe2() { throw null; } ``` Generates this dex code: ``` .method uoe()Ljava/lang/Object; new-instance v0, Ljava/lang/UnsupportedOperationException; invoke-direct {v0}, Ljava/lang/UnsupportedOperationException;-><init>()V throw v0 .end method .method npe2()Ljava/lang/Object; const/4 v0, 0x0 throw v0 .end method ``` Which generates this OAT code: ``` java.lang.Object SomeProto.uoe() [84 bytes] 0x000081c0 sub x16, sp, #0x2000 (8192) 0x000081c4 ldr wzr, [x16] StackMap[0] native_pc=0x41c8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000081c8 str x0, [sp, #-48]! 0x000081cc str x22, [sp, #24] 0x000081d0 stp x23, lr, [sp, #32] 0x000081d4 ldr x21, [x21] StackMap[1] native_pc=0x41d8, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000081d8 mov x22, x1 0x000081dc adrp x0, #+0x4000 (addr 0x0000c000) 0x000081e0 ldr w0, [x0, #4] 0x000081e4 ldr lr, [tr, #464] ; pAllocObjectInitialized 0x000081e8 blr lr StackMap[2] native_pc=0x41ec, dex_pc=0x0, register_mask=0x400000, stack_mask=0b 0x000081ec dmb ishst 0x000081f0 mov x1, x0 0x000081f4 mov x23, x1 0x000081f8 adrp x0, #+0x4000 (addr 0x0000c000) 0x000081fc ldr w0, [x0, #12] 0x00008200 ldr lr, [x0, #24] 0x00008204 blr lr StackMap[3] native_pc=0x4208, dex_pc=0x2, register_mask=0xc00000, stack_mask=0b 0x00008208 mov x0, x23 0x0000820c ldr lr, [tr, #1264] ; pDeliverException 0x00008210 blr lr StackMap[4] native_pc=0x4214, dex_pc=0x5, register_mask=0xc00000, stack_mask=0b java.lang.Object SomeProto.npe2() [36 bytes] 0x000080d0 sub x16, sp, #0x2000 (8192) 0x000080d4 ldr wzr, [x16] StackMap[0] native_pc=0x40d8, dex_pc=0x0, register_mask=0x0, stack_mask=0b 0x000080d8 str x0, [sp, #-32]! 0x000080dc stp x22, lr, [sp, #16] 0x000080e0 ldr x21, [x21] StackMap[1] native_pc=0x40e4, dex_pc=0x0, register_mask=0x2, stack_mask=0b 0x000080e4 mov x22, x1 0x000080e8 mov w0, #0x0 0x000080ec ldr lr, [tr, #1264] ; pDeliverException 0x000080f0 blr lr StackMap[2] native_pc=0x40f4, dex_pc=0x1, register_mask=0x400000, stack_mask=0b ``` This saves 84-36 = 48 bytes of OAT per method. PiperOrigin-RevId: 684620833
yordis
pushed a commit
to yordis/protobuf
that referenced
this pull request
Dec 8, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.