Join GitHub today
cmd/compile: readonly analysis of functions accepting byte arguments #29810
In #29802, @rillig observes that encoding/hex.Decode only reads from its
The obvious question is how often this occurs, and whether it justifies the cost (implementation, maintenance, code complexity, execution time).
I thought that we already had an issue for this, but I can't find it.
The use case for maps is I think the other way around where the compiler can eliminate the copy for conversion to string (as opposed to from string). In contrast ranging over byte(string) the copy is avoided by the compiler. However both require knowledge that the byte slice will not change.
I dont think we need to make the distinction if the argument is passed in as a conversion like for maps. If we have a compiler pass that can evaluate if a byte slice is ever written to within a specific range even in functions its passed to we can generally avoid the copy on conversion from/to string (even if its stand alone before any call e.g. map operation) and also use it to prove that e.g. for x := range string(a) if a is never modified in the for loop the copy can be avoided #27148.
A problem might be that walk pass seems not optimal for this kind of analysis and that after ssa/call construction it might be too low level already. If we had a high level ssa structure with calls as high level concepts to optimize on, some new and existing optimizations maybe easier to implement and maintain. I dont remember the issue but this IIRC this was discussed before. (Maybe I was thinking of #17728)
Yes, thanks. :) I knew there was one. I'll close this one.
Indeed. Although this might be a common enough case, with a simple enough analysis, that it's worth doing even the lower-power version available during walk. Might be worth prototyping.
Yes, this ordering issue is a perennial problem. It has also showed up in discussions of inlining, purity analysis, DCE, and more.