Implement an address_insignificant attribute#8421
Implement an address_insignificant attribute#8421alexcrichton wants to merge 1 commit intorust-lang:masterfrom
address_insignificant attribute#8421Conversation
This can be applied to statics and it will indicate that LLVM will attempt to merge the constant in .data with other statics. I have preliminarily applied this to all of the statics generated by the new `ifmt!` syntax extension. I compiled a file with 1000 calls to `ifmt!` and a separate file with 1000 calls to `fmt!` to compare the sizes, and the results were: fmt 310k ifmt (before) 529k ifmt (after) 202k This now means that ifmt! is both faster and smaller than fmt!, yay!
|
In the long term, shouldn't |
|
I found out that llvm won't optimize this unless the constant also has an internal-type linkage. Thatmeans that statics marked Additionally though, TLS keys all have significant addresses, and in my opinion it would be a real bummer to have to mark all of our tls keys with For now I think that normal statics shouldn't have this thrown on by default for the TLS reason, but other than that use case it's certainly worth a shot to see what starts crashing and burning. |
This can be applied to statics and it will indicate that LLVM will attempt to merge the constant in .data with other statics. I have preliminarily applied this to all of the statics generated by the new `ifmt!` syntax extension. I compiled a file with 1000 calls to `ifmt!` and a separate file with 1000 calls to `fmt!` to compare the sizes, and the results were: ``` fmt 310k ifmt (before) 529k ifmt (after) 202k ``` This now means that ifmt! is both faster and smaller than fmt!, yay!
Replace a few paths with diagnostic items A fairly small change towards rust-lang#5393 changelog: none
This can be applied to statics and it will indicate that LLVM will attempt to
merge the constant in .data with other statics.
I have preliminarily applied this to all of the statics generated by the new
ifmt!syntax extension. I compiled a file with 1000 calls toifmt!and aseparate file with 1000 calls to
fmt!to compare the sizes, and the resultswere:
This now means that ifmt! is both faster and smaller than fmt!, yay!