https://llvm.org/bugs/show_bug.cgi?id=26519
Mark Millard changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #15 from Mark Millard ---
(In reply to comment #14)
My interpretation of this is that the "lwz r30,24(r1)" is simply out
of sequence and should be later in the sequence:
> 0x0181b01c <__floatdidf+80>: lwz r30,24(r1) <<<=== not here
> 0x0181b020 <__floatdidf+84>: lfs f2,0(r3)
> 0x0181b024 <__floatdidf+88>: lwz r3,-12(r30)
> 0x0181b028 <__floatdidf+92>: lfs f0,0(r6)
> 0x0181b02c <__floatdidf+96>: lfs f12,0(r3)
> 0x0181b030 <__floatdidf+100>: fsubf0,f1,f0
> 0x0181b034 <__floatdidf+104>: fmulf0,f0,f2
> 0x0181b038 <__floatdidf+108>: faddf0,f0,f12
> 0x0181b03c <__floatdidf+112>: faddf1,f13,f0
lwz r30,24(r1) <<=== instead here
> 0x0181b040 <__floatdidf+116>: addir1,r1,32
> 0x0181b044 <__floatdidf+120>: mtlrr0
> 0x0181b048 <__floatdidf+124>: blr
(addresses not adjusted for the change in the above)
So that r30 would be restored between the main activity being
finished and r1 being adjusted (popping the stack frame). Of
course any place after the last local r30 use [after -12(r30)]
up to where I show it would also work.
I reported this issue as a comment on 26519 because I'm guessing
that the ordering problem is tied to trying to trying to avoid the
stack-handling ABI violations for FreeBSD: another incompleteness
in the coverage of the stack handling. If it is not that then a
separate submittal would likely be appropriate.
Since I'm allowed to I'm going to change the status to reopened so
that it does not look to have been fully fixed. Let me know if this
is inappropriate since I would not be the one fixing it.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs