-
-
Notifications
You must be signed in to change notification settings - Fork 488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug with if-else #3
Comments
Thank you for the report! I will take a look tomorrow. But I'm surethat modifying the condition to "if (cur == src || src == NULL)" will not fix the problem, only this simplified integration test-case. It will be most probably related to x86context.cpp line 4680. |
Thank you! In the second example jg should go to l3, then it passes the test with "if (cur == src || src == NULL)" |
Here is the test for floating-point numbers. The test fails on x64 if you try to call external function (print) or accept arguments from GpVars.
Since this fail is related to function calling but not conditional branching here is a more simple example:
|
Ok I located/fixed the first problem and can reproduce also the removeUnreachableCode() problem. Will work on fixing these today. |
Ok so I can now run the second code, but I think there is a small bug in the test-case, because it will run forever, see:
So I will fix a bit and commit these test cases and fixes. |
Added more test cases based on Issue #3 Minor changes.
Thank you! With new version I came across with two more bugs of conditional branching.
|
I think I can fix these today, can reproduce. |
Please check it out if the referred commit fixes the issues with register-allocator. The problem with floating point is not connected with these issues and I will fix it by another commit. |
Yes it works! Thank you! There seems to be the general problem with an external function call that you don't know which registers the function is going to use. So you either have to backup and restore all the used registers or analyze an external bytecode to detect register usage. There should be the same convention on external function calling for static compiler, because it faces the same problem when calling jitted code. Most probably it reuses registers if it can predict the usage inside external function (so called inlining) but for totally unknown functions it has no way but backup registers. The following example should illustrate the problem, please see comments inside:
|
Please see the calling convention on page 10 here: On windows xmm6-xmm15 are garanteed to be the same after exit from function, so those may be used to backup variables. Also, it seems that generated function should follow the convention. On unix there is no such garantee, so you should use memory. |
Well, I'm still working on the issue, and it is basically caused by the fact that x86 returns float/double in st0, thus there has to be an extra check for this case. Compiler function-call automatically saves registers that are clobbered. Furthermore I did some other improvements and I'm still fixing the x86 compiler. |
The status of this issue: Currently only unsafe returns are st(0) and st(1), which are only used on x86 (not on x64). I will fix these soon. Also unsafe is conversion of return value / function argument - was really thinking about removing this feature, but I think that it's necessary. |
Floating point values returning in st0/st1 are now supported. |
Test cases for testx86.cpp:
// Ignore if both states are equal.
if (cur == src)
with
if (cur == src || src == NULL)
I know this is the bad way, but it works.
struct X86Test_IfElseInt : public X86Test {
X86Test_IfElseInt() : X86Test("[IfElse] If-else statement") {}
};
Commenting out removeUnreachableCode() in compile() helps a little, but then it fails anyway.
struct X86Test_IfElseInt2 : public X86Test {
X86Test_IfElseInt2() : X86Test("[IfElse] If-else statement 2") {}
};
There are some additional problems when comparing and working with floating-point values with Xmm variables. I have to do a redundant mov operation inside each if-else brench, otherwise it fails on assertion:
Assertion failed: vd->getState() == kVarStateReg, file x86context_p.h, line 254
probably because I modified code as in example 1.
I can't provide example for this compatible with testx86.cpp, because for x86 I don't know how to make movs between GpVar and XmmVar.
The text was updated successfully, but these errors were encountered: