Mercurial > hg > index.cgi

diff 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
line wrap: on
line diff
--- a/extra/README	Sun Mar 27 21:46:18 2016 -0600
+++ b/extra/README	Tue Mar 29 21:21:49 2016 -0600
@@ -96,51 +96,15 @@
 NOTES ABOUT SPECIFIC PATCHES
 ============================
 
-gcc6809lw-4.6.4-2.patch
-
-This patch essentially disables the "soft registers". These were causing
-problems leading to compiler crashes. Removing the "t" constraint from
-the instruction patterns allowed various issues to go away. It is not clear
-if the original reasoning behind these soft registers is even valid any
-more.
-
-Also fixes a clearly incorrect comparision when determining if a constant
-fits in 16 bits. For clarity, both the 8 bit and 16 bit comparisons are
-replaced with straight forward range comparisons rather than the excessively
-clever scheme that was present before.
-
-gcc6809lw-4.6.4-3.patch
-
-This is identical to the -2 version except it fixes the crt0.S file so it
-builds properly with the --pragma=newsource option. In fact, it never did
-build properly due to spaces in operands anyway. However, since gcc6809
-doesn't come with a C library, it hasn't proved to be an issue.
-
-Patches to provide a proper crt0.S file based around the actual way lwtools
-works will be considered.
+Old gcc6809 patches have been removed to avoid confusion.
 
-It's also worth noting that there are features inherited from previous
-versions of gcc6809 that are not properly supported by these patches. In
-particular, banking and "far calls" are not supported because there are no
-targets supported by lwtools that do anything meaningful in the face of such
-things. Patches to clean that up are also welcome. Either to do something
-meaningful or to remove such features entirely.
-
-gcc6809lw-4.6.4-4.patch
+The -6 patch fixes a code generation ICE. The previous -4 patch fixed a code
+generation error that could have a substantial impact. The -3 patch fixed
+some compatibilty with new lwtools versions. The -2 patch fixed a major set
+of ICEs by completely removing the "soft registers" business. They're
+apparently not needed with gcc 4.6.x at all and it's not clear they were
+even needed with gcc 4.3.x. They also had the side effect of causing things
+to break even if they weren't in use so they had to go. In other words, the
+-6 patch is the current best version to use so there's no point including
+the old ones.
 
-This is identical to the -3 version except it fixes a code generation bug
-that showed up under optimization. It would result in the sense of a branch
-following a subtraction being inverted for whatever reason. This change
-seems to fix that.
-
-gcc6809lw-4.6.4-5.patch
-
-This is the same as the -4 version except it removes two instruction
-patterns that gcc was choosing to use in cases where they simply did not
-apply and, thus, it was getting confused and leading to an ICE. These
-patterns were a useful optmization for incrementing and decrementing 16 bit
-values in memory but if the compiler core is going to select them in cases
-where it really isn't an increment or decrement in place, the patterns are
-not useful. The resulting code is slightly less good than it could be under
--Os but it's still correct.
-