Optimized the size of PNG images. 172KB > 143KB #839
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
Used optpng + pngout + deflopt.
reactormonk
added a commit
that referenced
this pull request
Jan 24, 2014
Optimized the size of PNG images. 172KB > 143KB
reactormonk
added a commit
to reactormonk/nim
that referenced
this pull request
Apr 7, 2014
Optimized the size of PNG images. 172KB > 143KB
reactormonk
added a commit
that referenced
this pull request
Apr 11, 2014
Optimized the size of PNG images. 172KB > 143KB
Clyybber
pushed a commit
to Clyybber/Nim
that referenced
this pull request
Sep 16, 2023
## Summary Centralize the decision about the underlying storage types for enum values in semantic analysis. Since the decision now happens in a single place instead of being scattered across the compiler, this makes it significantly easier to change the enum storage behaviour later on. In addition, this fixes two bugs with 1- and 2-byte enum values (which use unsigned integer storage) where the most significant bit was set that affected code running in the VM: - loading the values from memory resulted in non-valid values - (only affected the VM and JS backend) storing them inside aggregate `const`s resulted in them having invalid values at run-time ## Details The key changes are: - `tyEnum` now stores the storage type in the second type slot, meaning that `skipTypes(tyEnum)` yields the storage type - size and alignment computation redirects to the storage type - `isUnsigned` considers a `tyEnum`'s storage type - the code generators use the `tyEnum`'s provided storage type and don't decide it themselves Using the second type slot of `tyEnum` is done for both forward- and backward-compatibility: it's possible that some of the current code still depends on an enum type's first slot always being `nil`, and in the future the slot could possibly be used to store the enum's base type. The storage type is directly set on enum definition (`semEnum`). Before analyzing the enum fields, a preliminary storage type (`tyInt`) is already added for the enum: this allows for the enum's values to be used *before* the enum type is fully produced. Once the full value range is known, the correct storage type is selected. Choosing the storage type happens in the same way as it previously did in the C code generator (`ccgtypes`). Apart from the information now being available during semantic analysis already, this only affects the VM target, where non-negative enum values requiring 32 or 64 bit of storage were previously stored as unsigned integer (they're now stored as *signed* integers, in line with the C target). For the VM code generator, `tyEnum` is added to the `IrrelevantTypes` set, meaning that the code generator now transparently treats all enum types as their storage type, with an exception being made for the to- string operation.
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.
Used optpng + pngout + deflopt.