[Bug target/30255] register spills in x87 unit need to be 80-bit, not 64
------- Comment #7 from whaley at cs dot utsa dot edu 2006-12-19 00:31 -------
>Depends on what you mean by fixable by the programmer because most people don't
know anything about precusion issues.
Most people don't know programming at all, so I guess you are suggesting that
errors that are fixable at the source-code level must nonetheless always be
fixed by the compiler? More to the point, the people who truly care about
precision *are* often aware of these kinds of fixes, but they are helpless in
this case, unlike for bug 323 (which is why they should not be conflated).
My point was that for bug 323, there is something the user can do to fix, and
that something does not hurt overall performance or accuracy. Since the
problem I reported is caused completely by gcc, impacts accuracy in the same
way as reordering (which gcc prohibits), and there is nothing that the user can
do to fix without drastic loss of performance or accuracy, gcc is the only
place it can be fixed. This problem is a narrow discrete case that can clearly
be fixed by gcc, whereas 323 is a broad class of problems which cannot be fixed
without adding to the C language the concept of mixed precisions within a type.
Therefore, I strongly believe that it is perfectly valid to say that 323
cannot be solved in gcc, but clearly untrue to say that about this case, and so
this bug report should have been closed as "we don't care", not as "duplicate".
>This was a design of the x86 back-end because it gives a nice speed.
The fix I suggested would only slow spill (note: I mean gcc-spilled code, not
explicit load/stores by the programmer) code, and would therefore make
noticable performance difference in very few cases. Note that unlike the
straw-man of bug 323 I am *not* advocating gcc handle all extra precision
behavior, just its undetectable spill rounding.
If the performance issue is greater than I suspect, obviously there could be a
flag for this behavior. I find it a bit anomolous that a compiler that is so
picky about bit-level accuracy that it forbids reordering operations without a
special flag, feels free to randomly round in an algorithm, even though the fix
would not hurt performance as much as not performing reordering optimizations
does, and introduces the same type of error. That it does so on the most
common platform on earth just adds to the beauty :)
Thanks,
Clint
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Reply to: