I'm convinced we've successfully identified the problem, but
unfortunately I added barriers liberally and it still failed.
Gabe
int newrnd = M5_FE_TONEAREST;
switch (Fsr<31:30>) {
case 0: newrnd = M5_FE_TONEAREST; break;
case 1: newrnd = M5_FE_TOWARDZERO; break;
case 2: newrnd = M5_FE_UPWARD; break;
case 3: newrnd = M5_FE_DOWNWARD; break;
}
__asm__ __volatile__ ("" ::: "memory");
int oldrnd = m5_fegetround();
__asm__ __volatile__ ("" ::: "memory");
m5_fesetround(newrnd);
__asm__ __volatile__ ("" ::: "memory");
"""
fp_code += code
fp_code += """
__asm__ __volatile__ ("" ::: "memory");
m5_fesetround(oldrnd);
__asm__ __volatile__ ("" ::: "memory");
"""
fp_code = filterDoubles(fp_code)
iop = InstObjParams(name, Name, 'SparcStaticInst', fp_code, flags)
header_output = BasicDeclare.subst(iop)
decoder_output = BasicConstructor.subst(iop)
decode_block = BasicDecode.subst(iop)
exec_output = BasicExecute.subst(iop)
}};
On 10/26/11 07:10, Steve Reinhardt wrote:
> 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
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
