- 04 Oct, 2011 6 commits
-
-
Paul Borman authored
Fixes #2324. R=r, r CC=golang-dev https://golang.org/cl/5180044
-
Russ Cox authored
The loop recognizer uses the standard dominance frontiers but gets confused by dead code, which has a (not explicitly set) rpo number of 0, meaning it looks like the head of the function, so it dominates everything. If the loop recognizer encounters dead code while tracking backward through the graph it fails to recognize where it started as a loop, and then the optimizer does not registerize values loaded inside that loop. Fix by checking rpo against rpo2r. Separately, run a quick pass over the generated code to squash JMPs to JMP instructions, which are convenient to emit during code generation but difficult to read when debugging the -S output. A side effect of this pass is to eliminate dead code, so the output files may be slightly smaller and the optimizer may have less work to do. There is no semantic effect, because the linkers flatten JMP chains and delete dead instructions when laying out the final code. Doing it here too just makes the -S output easier to read and more like what the final binary will contain. The "dead code breaks loop finding" bug is thus fixed twice over. It seemed prudent to fix loopit separately just in case dead code ever sneaks back in for one reason or another. R=ken2 CC=golang-dev https://golang.org/cl/5190043
-
Gustavo Niemeyer authored
R=golang-dev, rsc, gustavo, r, borman CC=golang-dev https://golang.org/cl/4981049
-
Joe Poirier authored
Example: #cgo windows LDFLAGS: -LC:\\WINDOWS\\system32 R=alex.brainman, go.peter.90, golang-dev, rsc CC=golang-dev https://golang.org/cl/5154042
-
Brad Fitzpatrick authored
R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/5179045
-
Nigel Tao authored
The spin-off renames some types. The new names are simply better: image.Color -> color.Color image.ColorModel -> color.Model image.ColorModelFunc -> color.ModelFunc image.PalettedColorModel -> color.Palette image.RGBAColor -> color.RGBA image.RGBAColorModel -> color.RGBAModel image.RGBA64Color -> color.RGBA64 image.RGBA64ColorModel -> color.RGBA64Model (similarly for NRGBAColor, GrayColorModel, etc) The image.ColorImage type stays in the image package, but is renamed: image.ColorImage -> image.Uniform The image.Image implementations (image.RGBA, image.RGBA64, image.NRGBA, image.Alpha, etc) do not change their name, and gain a nice symmetry: an image.RGBA is an image of color.RGBA, etc. The image.Black, image.Opaque uniform images remain unchanged (although their type is renamed from image.ColorImage to image.Uniform). The corresponding color types (color.Black, color.Opaque, etc) are new. Nothing in the image/ycbcr is renamed yet. The ycbcr.YCbCrColor and ycbcr.YCbCrImage types will eventually migrate to color.YCbCr and image.YCbCr, but that will be a separate CL. R=r, bsiegert CC=golang-dev https://golang.org/cl/5132048
-
- 03 Oct, 2011 5 commits
-
-
Rob Pike authored
Fix for new regexp library ($ isn't end of line any more). Don't assume . is in PATH. R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/5175052
-
Brad Fitzpatrick authored
This implements a replacer for when all old strings are single bytes, but new values are not. BenchmarkHTMLEscapeNew 1000000 1090 ns/op BenchmarkHTMLEscapeOld 1000000 2049 ns/op R=rsc CC=golang-dev https://golang.org/cl/5176043
-
Russ Cox authored
My previous CL: changeset: 9645:ce2e5f44b310 user: Russ Cox <rsc@golang.org> date: Tue Sep 06 10:24:21 2011 -0400 summary: gc: unify stack frame layout introduced a bug wherein no variables were being registerized, making Go programs 2-3x slower than they had been before. This CL fixes that bug (along with some others it was hiding) and adds a test that optimization makes at least one test case faster. R=ken2 CC=golang-dev https://golang.org/cl/5174045
-
Brad Fitzpatrick authored
When all old & new string values are single bytes, byteReplacer is now used, instead of the generic algorithm. BenchmarkGenericMatch 10000 102519 ns/op BenchmarkByteByteMatch 1000000 2178 ns/op fast path, when nothing matches: BenchmarkByteByteNoMatch 1000000 1109 ns/op comparisons to multiple Replace calls: BenchmarkByteByteReplaces 100000 16164 ns/op comparison to strings.Map: BenchmarkByteByteMap 500000 5454 ns/op R=rsc CC=golang-dev https://golang.org/cl/5175050
-
Hector Chu authored
R=golang-dev, jsing, alex.brainman, cw, rsc CC=golang-dev https://golang.org/cl/5166047
-
- 01 Oct, 2011 3 commits
-
-
Joel Sing authored
R=golang-dev, mikioh.mikioh, hectorchu CC=golang-dev https://golang.org/cl/5173043
-
Russ Cox authored
The map implementation was using the C idiom of using a pointer just past the end of its table as a limit pointer. Unfortunately, the garbage collector sees that pointer as pointing at the block adjacent to the map table, pinning in memory a block that would otherwise be freed. Fix by making limit pointer point at last valid entry, not just past it. Reviewed by Mike Burrows. R=golang-dev, bradfitz, lvd, r CC=golang-dev https://golang.org/cl/5158045
-
Mikio Hara authored
R=golang-dev, dave CC=golang-dev https://golang.org/cl/5137042
-
- 30 Sep, 2011 10 commits
-
-
David Symonds authored
These don't do anything useful; they are just here to fix the build. R=golang-dev TBR=r CC=golang-dev https://golang.org/cl/5154048
-
David Symonds authored
R=golang-dev, r CC=golang-dev https://golang.org/cl/5157045
-
Russ Cox authored
Breaks on Linux/386 during parallel sync tests. TBR=r CC=golang-dev https://golang.org/cl/5168044
-
Hector Chu authored
Add osyield and usleep as required by recent GC changes. R=golang-dev, r, dsymonds, rsc, r CC=golang-dev https://golang.org/cl/5156042
-
Robert Griesemer authored
Benchmark results (best of 3 runs): old: suffixarray.BenchmarkSaveRestore 1 1931909000 ns/op 28.21 MB/s new: suffixarray.BenchmarkSaveRestore 5 429721800 ns/op 117.14 MB/s R=golang-dev, r CC=golang-dev https://golang.org/cl/5161043
-
Rob Pike authored
Add place holder for runtime.osyield. R=golang-dev CC=golang-dev https://golang.org/cl/5149049
-
Russ Cox authored
Running test/garbage/parser.out. On a 4-core Lenovo X201s (Linux): 31.12u 0.60s 31.74r 1 cpu, no atomics 32.27u 0.58s 32.86r 1 cpu, atomic instructions 33.04u 0.83s 27.47r 2 cpu On a 16-core Xeon (Linux): 33.08u 0.65s 33.80r 1 cpu, no atomics 34.87u 1.12s 29.60r 2 cpu 36.00u 1.87s 28.43r 3 cpu 36.46u 2.34s 27.10r 4 cpu 38.28u 3.85s 26.92r 5 cpu 37.72u 5.25s 26.73r 6 cpu 39.63u 7.11s 26.95r 7 cpu 39.67u 8.10s 26.68r 8 cpu On a 2-core MacBook Pro Core 2 Duo 2.26 (circa 2009, MacBookPro5,5): 39.43u 1.45s 41.27r 1 cpu, no atomics 43.98u 2.95s 38.69r 2 cpu On a 2-core Mac Mini Core 2 Duo 1.83 (circa 2008; Macmini2,1): 48.81u 2.12s 51.76r 1 cpu, no atomics 57.15u 4.72s 51.54r 2 cpu The handoff algorithm is really only good for two cores. Beyond that we will need to so something more sophisticated, like have each core hand off to the next one, around a circle. Even so, the code is a good checkpoint; for now we'll limit the number of gc procs to at most 2. R=dvyukov CC=golang-dev https://golang.org/cl/4641082
-
Mike Samuel authored
This is a possible optimization. I'm not sure the complexity is worth it. The new benchmark in escape_test is 46us without and 35us with the optimization. R=nigeltao CC=golang-dev https://golang.org/cl/5168041
-
Nigel Tao authored
R=adg TBR=adg CC=golang-dev https://golang.org/cl/5154046
-
Mike Samuel authored
This removes a few cases from escapeAction and clarifies the responsibilities of urlFilter which no longer does any escaping or normalization. It is now solely a filter. R=nigeltao CC=golang-dev https://golang.org/cl/5162043
-
- 29 Sep, 2011 10 commits
-
-
Brad Fitzpatrick authored
R=gustavo, rsc, borman, dave, kevlar, nigeltao, dvyukov, kardianos, fw, r, r, david.crawshaw CC=golang-dev https://golang.org/cl/4973055
-
Brad Fitzpatrick authored
... protects this optimization from future well-meaning Gophers looking to delete unused code. :) R=gri CC=golang-dev https://golang.org/cl/5165041
-
Ian Lance Taylor authored
R=gri CC=golang-dev https://golang.org/cl/5164041
-
Luuk van Dijk authored
The type to cast the elements to was stolen from a field that's no longer there. R=rsc CC=golang-dev https://golang.org/cl/5143050
-
Rob Pike authored
Simpler concept, and it turns a queue into a stack. Speeds up benchmarks noticeably. Before: fmt_test.BenchmarkSprintfEmpty 10000000 282 ns/op fmt_test.BenchmarkSprintfString 2000000 910 ns/op fmt_test.BenchmarkSprintfInt 5000000 723 ns/op fmt_test.BenchmarkSprintfIntInt 1000000 1071 ns/op fmt_test.BenchmarkSprintfPrefixedInt 1000000 1108 ns/op fmt_test.BenchmarkScanInts 1000 2239510 ns/op fmt_test.BenchmarkScanRecursiveInt 1000 2365432 ns/op After: fmt_test.BenchmarkSprintfEmpty 10000000 232 ns/op fmt_test.BenchmarkSprintfString 2000000 837 ns/op fmt_test.BenchmarkSprintfInt 5000000 590 ns/op fmt_test.BenchmarkSprintfIntInt 2000000 910 ns/op fmt_test.BenchmarkSprintfPrefixedInt 2000000 996 ns/op fmt_test.BenchmarkScanInts 1000 2210715 ns/op fmt_test.BenchmarkScanRecursiveInt 1000 2367800 ns/op R=rsc, r CC=golang-dev https://golang.org/cl/5151044
-
Rob Pike authored
The letter is a holdover from C and unnecessary in Go. Gofix module included. Fixes #2306. R=golang-dev, gri, dsymonds CC=golang-dev https://golang.org/cl/5158043
-
Robert Griesemer authored
R=rsc CC=golang-dev https://golang.org/cl/5163041
-
Russ Cox authored
R=ken2 CC=golang-dev https://golang.org/cl/5161041
-
Robert Griesemer authored
R=rsc, r, nigeltao, r, dsymonds CC=golang-dev https://golang.org/cl/5146048
-
Russ Cox authored
R=golang-dev, bradfitz, r CC=golang-dev https://golang.org/cl/5141051
-
- 28 Sep, 2011 6 commits
-
-
Mike Samuel authored
HTML5 allows embedded SVG and MathML. Code searches show SVG is used for graphing. This changes transition to deal with constructs like <svg xmlns:xlink="http://www.w3.org/1999/xlink"> It changes attr and clients to call a single function that combines the name lookup and "on" prefix check to determine an attribute value type given an attribute name. That function uses heuristics to recognize that xlink:href and svg:href have URL content, and that data-url is likely contains URL content, since "javascript:" injection is such a problem. I did a code search over a closure templates codebase to determine patterns of custom attribute usage. I did something like $ find . -name \*.soy | \ xargs egrep perl -ne 'while (s/\b((data-|\w+:)\w+)\s*=//) { print "$1\n"; }' | \ sort | uniq to produce the list at the bottom. Filtering that by egrep -i 'src|url|uri' produces data-docConsumptionUri data-docIconUrl data-launchUrl data-lazySrc data-pageUrl data-shareurl data-suggestServerUrl data-tweetUrl g:secondaryurls g:url which seem to match all the ones that are likely URL content. There are some short words that match that heuristic, but I still think it decent since any custom attribute that has a numeric or enumerated keyword value will be unaffected by the URL assumption. Counterexamples from /usr/share/dict: during, hourly, maturity, nourish, purloin, security, surly Custom attributes present in existing closure templates codebase: buzz:aid data-a data-action data-actor data-allowEqualityOps data-analyticsId data-bid data-c data-cartId data-categoryId data-cid data-command data-count data-country data-creativeId data-cssToken data-dest data-docAttribution data-docConsumptionUri data-docCurrencyCode data-docIconUrl data-docId data-docPrice data-docPriceMicros data-docTitle data-docType data-docid data-email data-entityid data-errorindex data-f data-feature data-fgid data-filter data-fireEvent data-followable data-followed data-hashChange data-height data-hover data-href data-id data-index data-invitable data-isFree data-isPurchased data-jid data-jumpid data-launchUrl data-lazySrc data-listType data-maxVisiblePages data-name data-nid data-nodeid data-numItems data-numPerPage data-offerType data-oid data-opUsesEquality data-overflowclass data-packageName data-pageId data-pageUrl data-pos data-priceBrief data-profileIds data-query data-rating data-ref data-rentalGrantPeriodDays data-rentalactivePeriodHours data-reviewId data-role data-score data-shareurl data-showGeLe data-showLineInclude data-size data-sortval data-suggestServerType data-suggestServerUrl data-suggestionIndex data-tabBarId data-tabBarIndex data-tags data-target data-textColor data-theme data-title data-toggletarget data-tooltip data-trailerId data-transactionId data-transition data-ts data-tweetContent data-tweetUrl data-type data-useAjax data-value data-width data-x dm:index dm:type g:aspects g:decorateusingsecondary g:em g:entity g:groups g:id g:istoplevel g:li g:numresults g:oid g:parentId g:pl g:pt g:rating_override g:secondaryurls g:sortby g:startindex g:target g:type g:url g:value ga:barsize ga:css ga:expandAfterCharsExceed ga:initialNumRows ga:nocancelicon ga:numRowsToExpandTo ga:type ga:unlockwhenrated gw:address gw:businessname gw:comment gw:phone gw:source ng:controller xlink:href xml:lang xmlns:atom xmlns:dc xmlns:jstd xmlns:ng xmlns:og xmlns:webstore xmlns:xlink R=nigeltao CC=golang-dev https://golang.org/cl/5119041
-
Mike Samuel authored
The normalization that prevents element name and comment injection in <{{.}} by converting it to <{{.}} breaks <!DOCTYPE html> Instead of splitting states to have a start of document state and a text state, I whitelist <!DOCTYPE. R=nigeltao CC=golang-dev https://golang.org/cl/5131051
-
Russ Cox authored
*** This is a design review, not a code review. *** Feel free to reply to the mail instead of picking out individual lines to comment on in Rietveld. This command, go, will replace both gomake/make and goinstall. Make will stick around only for building our C commands and perhaps package runtime. In normal use while developing you'd run commands like go compile go test go clean go install which apply to the package in the current directory. To operate on code written by others, you add an explicit package path: go get gopath.googlecode.com/hg/oauth go test gopath.googlecode.com/hg/oauth The script.txt file is a script showing the output of the various help commands that the command has. (Right now, all the command can do is print help messages.) R=golang-dev, bradfitz, kevlar, r, edsrzf, gri, adg, rogpeppe, r CC=golang-dev https://golang.org/cl/5019045
-
Brad Fitzpatrick authored
This is just a new API to do many replacements at once. While the point of this API is to be faster than doing replacements one at a time, the implementation in this CL has the optimizations removed and may actually be slower. Future CLs will bring back & add optimizations. R=r, rsc, rogpeppe CC=golang-dev https://golang.org/cl/5081042
-
Brad Fitzpatrick authored
Fixes #2312 R=golang-dev, dsymonds CC=golang-dev https://golang.org/cl/5143049
-
Russ Cox authored
R=golang-dev, bradfitz, iant CC=golang-dev https://golang.org/cl/5127043
-