On Tue, 25 Oct 2011 11:53:29 -0700, Gabe Black <[email protected]>
wrote:
On 10/25/11 07:46, Steve Reinhardt wrote:
On Tue, Oct 25, 2011 at 2:30 AM, Gabe Black <[email protected]>
wrote:
I'm currently building binutils for SPARC, so hopefully I can
disassemble some things and get a better idea of what's going on.
It's
probably going to be really annoying to figure it out.
If it's really just an FP rounding error, it might not be that
hard... just
look at the examples from the trace of where it's going wrong,
figure out
what the right answer is, and focus on those few instructions. FP
is pretty
thoroughly specified by IEEE, so if it's not an outright compiler
bug, maybe
it's just some change in the default rounding settings or something.
Yeah, I think ISAs treat IEEE as a really good suggestion rather than
a
standard. ARM isn't strictly conformant, and neither is x86. The
default
rounding mode *is* standard, though, and I don't think is adjusted in
SPARC as a result of execution. If it changed somehow (unless I'm
forgetting where SPARC does that) it's a fairly significant problem.
Whether instructions generate +/- 0 in various situations may depend
on,
for instance, what order gcc decides to put the operands. I'm not
sure
that it does, but there are all kinds of weird, subtle behaviors with
FP, and you can't just fix how add works if x86 picked the wrong
thing.
Then you have to replace add, or semi-replace it by faking it out
with
other FP operations. If we're running real x87 instructions (we
shouldn't be in 64 bit mode, but we still could) then those use 80
bit
operands internally. Where and when rounding takes place depends on
when
those are moved in/out of the FPU, and will be different than true 64
bit operands. SSE based FP uses real 64 bit doubles, so that should
behave better. It should also be the default in 64 bit mode since the
compiler can assume some basic SSE support is present.
The rounding mode in SPARC is controlled by bits 31:30 of the FSR. My
guess is that this is actually the problem and gcc 4.5+ is doing some
code motion that is moving the actual fp code around our setting of the
rounding mode. Using one of the asm tricks to prevent code movement
(supposedly an empty asm() is supposed to be code barrier in gcc),
might fix the problem. I don't have time to try it, but
src/arch/sparc/isa/formats/basic.isa:145 looks like the right place.
Also, trying to run the regression with m5.debug might see if the
optimizer is at fault.
Ali
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
