I forgot to mention that I fired off a gem5.debug run before I went to bed last night, and it completed successfully. So it does appear to be the optimizer.
Steve On Wed, Oct 26, 2011 at 12:55 AM, Gabe Black <[email protected]> wrote: > On 10/25/11 22:28, Ali Saidi wrote: > > 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 > > Ah, ok, so we do set the mode apparently. I'll try gem5.debug and also > look at that template and see what I can see. Thanks Ali! > > Gabe > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
