RESOLVED FIXED 129045
[Win][LLINT] Incorrect stack alignment.
https://bugs.webkit.org/show_bug.cgi?id=129045
Summary [Win][LLINT] Incorrect stack alignment.
peavo
Reported 2014-02-19 09:08:24 PST
LLINT expects the stack to be aligned on 16 byte boundaries, but MSVC only aligns the stack on 4 byte boundaries, it seems.
Attachments
Patch (11.68 KB, patch)
2014-02-19 09:26 PST, peavo
no flags
peavo
Comment 1 2014-02-19 09:26:35 PST
Brent Fulgham
Comment 2 2014-02-19 10:16:21 PST
Comment on attachment 224637 [details] Patch Looks good to me! I think Mark should do the full review.
Michael Saboff
Comment 3 2014-02-19 10:21:24 PST
Comment on attachment 224637 [details] Patch Looks great. r=me.
peavo
Comment 4 2014-02-19 10:26:02 PST
(In reply to comment #3) > (From update of attachment 224637 [details]) > Looks great. r=me. Thanks for looking into this, guys :)
Geoffrey Garen
Comment 5 2014-02-19 10:37:23 PST
Windows is not the only platform on which the incoming stack is unaligned. For example, the same is true on ARM32. Can we share some of this code? It seems like aligning the stack is a generic action in the LLInt. We need to avoid adding too much Windows-specific cruft to the LLInt.
Mark Lam
Comment 6 2014-02-19 10:38:13 PST
Comment on attachment 224637 [details] Patch I don’t see the code to turn this code on in the build. It looks like it will still be using the C loop LLINT. Will you create another patch to turn this on? Thanks.
peavo
Comment 7 2014-02-19 10:49:06 PST
(In reply to comment #6) > (From update of attachment 224637 [details]) > I don’t see the code to turn this code on in the build. It looks like it will still be using the C loop LLINT. Will you create another patch to turn this on? Thanks. Yes you're right, it's still not turned on. Things seem to be running fine now with "normal" browsing, I'm not getting the stack alignment asserts, and the crashes I had was related to the double floating point type operations, which is fixed in this patch. However, there are alot of failures on the JSC stress tests. Should we look into those first, or should I post a patch to enable it, and look into the stress tests afterwards?
Mark Lam
Comment 8 2014-02-19 10:50:45 PST
(In reply to comment #7) > However, there are alot of failures on the JSC stress tests. > Should we look into those first, or should I post a patch to enable it, and look into the stress tests afterwards? Do those tests fail with the C Loop LLINT? If turning on the ASM LLINT and JIT does not introduce regressions, then yes, let’s turn it on.
WebKit Commit Bot
Comment 9 2014-02-19 10:55:42 PST
Comment on attachment 224637 [details] Patch Clearing flags on attachment: 224637 Committed r164374: <http://trac.webkit.org/changeset/164374>
WebKit Commit Bot
Comment 10 2014-02-19 10:55:44 PST
All reviewed patches have been landed. Closing bug.
peavo
Comment 11 2014-02-19 10:57:39 PST
(In reply to comment #8) > (In reply to comment #7) > > However, there are alot of failures on the JSC stress tests. > > Should we look into those first, or should I post a patch to enable it, and look into the stress tests afterwards? > > Do those tests fail with the C Loop LLINT? If turning on the ASM LLINT and JIT does not introduce regressions, then yes, let’s turn it on. Ok, sounds good, I will test that, and create a new patch if there are no regressions.
peavo
Comment 12 2014-02-19 10:58:51 PST
(In reply to comment #5) > Windows is not the only platform on which the incoming stack is unaligned. For example, the same is true on ARM32. Can we share some of this code? It seems like aligning the stack is a generic action in the LLInt. We need to avoid adding too much Windows-specific cruft to the LLInt. Is this something that could be done with a macro?
Mark Lam
Comment 13 2014-02-19 11:01:52 PST
(In reply to comment #11) > (In reply to comment #8) > > (In reply to comment #7) > > > However, there are alot of failures on the JSC stress tests. > > > Should we look into those first, or should I post a patch to enable it, and look into the stress tests afterwards? > > > > Do those tests fail with the C Loop LLINT? If turning on the ASM LLINT and JIT does not introduce regressions, then yes, let’s turn it on. > > Ok, sounds good, I will test that, and create a new patch if there are no regressions. Please also take note of what the failures are. If I remember correctly, most of them should be only timeouts. Turning on the baselineJIT and DFGJIT should help with that. I think there are also some 32-bit x86 failures still, but am not certain. Let’s make a record of what the failures are and whether they are regressions, and then, we can make an informed decision based on that.
Geoffrey Garen
Comment 14 2014-02-19 12:18:49 PST
> > Windows is not the only platform on which the incoming stack is unaligned. For example, the same is true on ARM32. Can we share some of this code? It seems like aligning the stack is a generic action in the LLInt. We need to avoid adding too much Windows-specific cruft to the LLInt. > > Is this something that could be done with a macro? Possibly. What we want, ideally, is a cross-platform idiom like this: if (!incomingStackIsAligned()) alignStack(); 'incomingStackIsAligned()' would return false on Windows and ARM32, and true on some other platforms. alignStack() might have a shared implementation on all platforms based on our abstract fp and sp registers -- or it might need a specific implementation on some platforms.
Note You need to log in before you can comment on or make changes to this bug.