Mercurial > hg > index.cgi

comparison extra/README @ 418:3832a68d83ef

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Fix internal compiler error on "var2 = var1 + 1" patterns This appears to be the correct fix. It was provided by Tormod Volden (debian.tormod@gmail.com). The final commit is substantially different from Tormod's submission mostly due to housecleaning (removing the old patches and updating the README). Tormod's comments follow. The original addhi_mem_1 "insn" instruction pattern /matches/ two memory operands, just with the /constraint/ that these are the same location. A pattern match tells the compiler "you should be able to use this, but you might have to work on it to meet the constraints". For typical constraints on registers the compiler can add "reloads", moving stuff between registers or from memory, until the constraints are met and the instruction can be used. However, in this case, no amount of reloads can make two memory locations the same if they already weren't, so the compiler breaks down and cries "unable to generate reloads". It seems this issue only appears if optimization is enabled. The proof is in gcc's reload.c and is left as an exercise to the reader. Limiting the matching pattern to identical memory operands avoids these situations, while allowing the common "var++" cases. References: The pattern/constraints difference is explained in https://gcc.gnu.org/onlinedocs/gccint/Simple-Constraints.html#index-other-register-constraints-3335
author William Astle <lost@l-w.ca>
date Tue, 29 Mar 2016 21:21:49 -0600
parents d7b7004b0883
children
comparison
equal deleted inserted replaced
417:d7b7004b0883 418:3832a68d83ef
94 The above is WOMM certified. YMMV. 94 The above is WOMM certified. YMMV.
95 95
96 NOTES ABOUT SPECIFIC PATCHES 96 NOTES ABOUT SPECIFIC PATCHES
97 ============================ 97 ============================
98 98
99 gcc6809lw-4.6.4-2.patch 99 Old gcc6809 patches have been removed to avoid confusion.
100 100
101 This patch essentially disables the "soft registers". These were causing 101 The -6 patch fixes a code generation ICE. The previous -4 patch fixed a code
102 problems leading to compiler crashes. Removing the "t" constraint from 102 generation error that could have a substantial impact. The -3 patch fixed
103 the instruction patterns allowed various issues to go away. It is not clear 103 some compatibilty with new lwtools versions. The -2 patch fixed a major set
104 if the original reasoning behind these soft registers is even valid any 104 of ICEs by completely removing the "soft registers" business. They're
105 more. 105 apparently not needed with gcc 4.6.x at all and it's not clear they were
106 even needed with gcc 4.3.x. They also had the side effect of causing things
107 to break even if they weren't in use so they had to go. In other words, the
108 -6 patch is the current best version to use so there's no point including
109 the old ones.
106 110
107 Also fixes a clearly incorrect comparision when determining if a constant
108 fits in 16 bits. For clarity, both the 8 bit and 16 bit comparisons are
109 replaced with straight forward range comparisons rather than the excessively
110 clever scheme that was present before.
111
112 gcc6809lw-4.6.4-3.patch
113
114 This is identical to the -2 version except it fixes the crt0.S file so it
115 builds properly with the --pragma=newsource option. In fact, it never did
116 build properly due to spaces in operands anyway. However, since gcc6809
117 doesn't come with a C library, it hasn't proved to be an issue.
118
119 Patches to provide a proper crt0.S file based around the actual way lwtools
120 works will be considered.
121
122 It's also worth noting that there are features inherited from previous
123 versions of gcc6809 that are not properly supported by these patches. In
124 particular, banking and "far calls" are not supported because there are no
125 targets supported by lwtools that do anything meaningful in the face of such
126 things. Patches to clean that up are also welcome. Either to do something
127 meaningful or to remove such features entirely.
128
129 gcc6809lw-4.6.4-4.patch
130
131 This is identical to the -3 version except it fixes a code generation bug
132 that showed up under optimization. It would result in the sense of a branch
133 following a subtraction being inverted for whatever reason. This change
134 seems to fix that.
135
136 gcc6809lw-4.6.4-5.patch
137
138 This is the same as the -4 version except it removes two instruction
139 patterns that gcc was choosing to use in cases where they simply did not
140 apply and, thus, it was getting confused and leading to an ICE. These
141 patterns were a useful optmization for incrementing and decrementing 16 bit
142 values in memory but if the compiler core is going to select them in cases
143 where it really isn't an increment or decrement in place, the patterns are
144 not useful. The resulting code is slightly less good than it could be under
145 -Os but it's still correct.
146