Closed Bug 1271972 Opened 8 years ago Closed 8 years ago

wasm: Implement i64.{clz,ctz,popcnt,eqz}

Categories

(Core :: JavaScript Engine: JIT, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox49 --- fixed

People

(Reporter: bbouvier, Assigned: bbouvier)

References

Details

Attachments

(4 files, 2 obsolete files)

      No description provided.
I have some basic masm-level code pending here, will upload soonish.
Depends on: 1272014
Attached patch 1.eqz.patch (obsolete) — Splinter Review
Attachment #8751363 - Flags: review?(sunfish)
For the ability to have int64 temporaries. I've tried making a templated class from which Int64Allocation/Int64Definition would inherit from, but doing so means having to redefine the ctors in the children classes, taking away all the interest of doing the inheritance at all.
Attachment #8751364 - Flags: review?(jdemooij)
Attached patch 3.unary.i64.patch (obsolete) — Splinter Review
This makes us pass i64.wast from the spec repo.
Attachment #8751365 - Flags: review?(sunfish)
Based on your ctz/clz patches, this hoists popcnt64 to the macro assembler. (if you want to comment on the code sequence when we don't have the popcnt instruction, i would ask kindly to do so in a review of the previous patch, please :))
Attachment #8751367 - Flags: review?(lhansen)
Attached patch 1.eqz.patchSplinter Review
Sorry for the spam, rebasing and histediting issues.
Attachment #8751363 - Attachment is obsolete: true
Attachment #8751363 - Flags: review?(sunfish)
Attachment #8751372 - Flags: review?(sunfish)
Sorry for the spam, rebasing and histediting issues.
Attachment #8751365 - Attachment is obsolete: true
Attachment #8751365 - Flags: review?(sunfish)
Attachment #8751373 - Flags: review?(sunfish)
Comment on attachment 8751367 [details] [diff] [review]
4. Hoist popcnt to the MacroAssembler

Review of attachment 8751367 [details] [diff] [review]:
-----------------------------------------------------------------

I landed the clz64/ctz64 patches, and I removed knownNotZero in the process.

Would it be useful to have an InvalidReg64?
Attachment #8751367 - Flags: review?(lhansen) → review+
Comment on attachment 8751364 [details] [diff] [review]
2.i64.infra.patch

Review of attachment 8751364 [details] [diff] [review]:
-----------------------------------------------------------------

Makes sense.

::: js/src/jit/LIR.h
@@ +635,5 @@
>  
>      void dump() const;
>  };
>  
> +class LInt64Definition

Maybe templatize LInt64Allocation (LInt64Value<T> or something), then we can add:

using LInt64Allocation = LInt64Value<LAllocation>;
using LInt64Definition = LInt64Value<LDefinition>;
Attachment #8751364 - Flags: review?(jdemooij) → review+
Comment on attachment 8751372 [details] [diff] [review]
1.eqz.patch

Review of attachment 8751372 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/asmjs/Wasm.cpp
@@ +277,5 @@
>        case Expr::Else:
>          return f.iter().readElse(nullptr, nullptr);
>        case Expr::End:
>          return f.iter().readEnd(nullptr, nullptr, nullptr);
> +      case Expr::I32Eqz:

The i64 form of eqz uses readConversion rather than readUnary because it needs a different type for the operand and result. It'd make sense to me to make the i32 form be a Conversion too, just to preserve what symmetry there is between i32 and i64, but we can go either way.
Attachment #8751372 - Flags: review?(sunfish) → review+
Comment on attachment 8751373 [details] [diff] [review]
3.unary.i64.patch

Review of attachment 8751373 [details] [diff] [review]:
-----------------------------------------------------------------

Cool!

Yay for the optimized path when the popcnt instruction is present. lzcnt and tzcnt are less critical, so we can do them in the future. :-).
Attachment #8751373 - Flags: review?(sunfish) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: