WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
151905
[JSC] FTLB3Output generates some invalid ZExt32
https://bugs.webkit.org/show_bug.cgi?id=151905
Summary
[JSC] FTLB3Output generates some invalid ZExt32
Benjamin Poulain
Reported
2015-12-04 20:45:39 PST
[JSC] FTLB3Output generates some invalid ZExt32
Attachments
Patch
(9.23 KB, patch)
2015-12-04 21:09 PST
,
Benjamin Poulain
no flags
Details
Formatted Diff
Diff
Patch
(1.84 KB, patch)
2015-12-19 08:32 PST
,
Benjamin Poulain
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Benjamin Poulain
Comment 1
2015-12-04 21:09:25 PST
Created
attachment 266702
[details]
Patch
Filip Pizlo
Comment 2
2015-12-04 21:46:08 PST
Comment on
attachment 266702
[details]
Patch Can you pick a consistent naming convention? I like zeroExtFooToBar. The zeroExtPtr and zeroExtTo32 feel like they should be renamed. I was previously hoping that zeroExt could continue to take a type as an argument and the B3 output could be smart enough to avoid emitting it when the requested type matches the input type. That feels like the better abstraction since we already know the type of the input and having one method is probably better than having three.
Benjamin Poulain
Comment 3
2015-12-04 21:49:10 PST
The reason for splitting into 3 methods is to make the cleanup easy later. Find any use, delete the call.
Filip Pizlo
Comment 4
2015-12-04 22:22:57 PST
(In reply to
comment #3
)
> The reason for splitting into 3 methods is to make the cleanup easy later. > Find any use, delete the call.
But this puts us in an inconsistent state. The current approach to this problem in other casts, like castToInt32, is: LValue castToInt32(LValue value) { return value->type() == B3::Int32 ? value : m_block->appendNew<B3::Value>(m_proc, B3::Trunc, origin(), value); } Why wouldn't that work here? You could just say: LValue zeroExt(LValue value, LType type) { return type == value->type() ? value : m_block->appendNew<B3::Value>(m_proc, B3::ZExt32, type, origin(), value); } If we don't want to do that for zeroExt(), then I think that your patch should also change how castToInt32() works, so that we are consistent. But I think that it makes sense for FTL::Output to abstract casts using the existing zeroExt(Value, Type) API. I think that this one API covers all of the things that your new functions do, and we could leave it this way forever. Even if we get rid of LLVM, a zeroExt(Value, Type) operation still makes sense.
Benjamin Poulain
Comment 5
2015-12-19 08:32:46 PST
Created
attachment 267687
[details]
Patch
WebKit Commit Bot
Comment 6
2015-12-19 11:02:17 PST
Comment on
attachment 267687
[details]
Patch Clearing flags on attachment: 267687 Committed
r194315
: <
http://trac.webkit.org/changeset/194315
>
WebKit Commit Bot
Comment 7
2015-12-19 11:02:23 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug