You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Observed over in https://reviews.llvm.org/D105657 , both our current variable location implementation and the instruction referencing stuff I've been working on are unable to cope with x87 variable locations. Both are unable to actually express where in registers variable values go.
The root cause is the baroqueness of x87 itself: it refers to registers as a stack, rather than just naming them directly. If we had a DBG_VALUE that referred to $st(1), we might need to issue additional DBG_VALUEs as the stack position of the value changed due to other FP instructions.
It's a significant pain in the neck, and VarLoc LiveDebugValues doesn't try to solve it. InstrRef LiveDebugValues doesn't try either. I suspect that interest in this matter is low (what with i386 processors being out of fashion for at least a decade) but thought I'd open the ticket in case there's something out there who this is relevant to.
The text was updated successfully, but these errors were encountered:
Extended Description
Observed over in https://reviews.llvm.org/D105657 , both our current variable location implementation and the instruction referencing stuff I've been working on are unable to cope with x87 variable locations. Both are unable to actually express where in registers variable values go.
The root cause is the baroqueness of x87 itself: it refers to registers as a stack, rather than just naming them directly. If we had a DBG_VALUE that referred to $st(1), we might need to issue additional DBG_VALUEs as the stack position of the value changed due to other FP instructions.
It's a significant pain in the neck, and VarLoc LiveDebugValues doesn't try to solve it. InstrRef LiveDebugValues doesn't try either. I suspect that interest in this matter is low (what with i386 processors being out of fashion for at least a decade) but thought I'd open the ticket in case there's something out there who this is relevant to.
The text was updated successfully, but these errors were encountered: