Omr: New IL Opcode Request: lumul

[hsoontie]

IL Opcode Name

lumul / long unsigned multiplication

Motivation

If added, lumul would perform multiplication between two unsigned long integers.

This opcode is needed because the evaluator that currently exists for long multiplication cannot distinguish whether its input is signed or unsigned from within its own scope, and as it stands, the evaluator is meant to handle both signed and unsigned multiplication. Adding lumul as an opcode would allow a second evaluator to be created alongside lmul to handle unsigned longs seperately, much like the existing imul and iumul.
An alternative would be to give the evaluator function some way of knowing whether its input was signed or unsigned (for example, adding an extra variable to the Node object being passed). This would likely require more overhead to implement, however.

Homogeneity

This opcode would work in the same way as lmul, with the signed/unsigned format being the only difference. The two would mimic the way imul and iumul work (one for signed, one for unsigned).

Structure

Data Type

uint64_t

Children

Would require two 64-bit integers for its operation.

Symbol Reference

N/A

IL Opcode Properties

The opcode's properties would be similar to those of iumul and imul.

Node flags

N/A

Control Flow

N/A

Operation

lumul would perform multiplication between two unsigned long integers.

Result Value

Evaluation would produce one result only, and would be as described above.

Side Effects

N/A

Anchoring

N/A

Scope

There is a reasonable chance of optimization occurring.
This IL opcode will be useful on all code generator backends in Eclipse OMR.
This opcode maps to a machine instruction.

Implementation Dependencies

• May require implementation in all backends

Performance

N/A

Testing Considerations

Tril tests will be developed.

IL Validation

N/A

[hsoontie]

Thoughts @0xdaryl , @Leonardo2718 , @knn-k , @aarongraham9 , @jeanlego , @marufunb ?

[Leonardo2718]

Also tagging @mstoodle @fjeremic @vijaysun-omr @andrewcraik @gita-omr

[Leonardo2718]

This opcode is needed because the evaluator that currently exists for long multiplication cannot distinguish whether its input is signed or unsigned from within its own scope, and as it stands, the evaluator is meant to handle both signed and unsigned multiplication.

Pedantic: I don't think this is true. Unsigned long integer multiplication is just not supported by the compiler at all.

Homogeneity

This opcode would work in the same way as lmul, with the signed/unsigned format being the only difference.

Probably also worth restating that it matches what is done with imul and iumul.

Children

N/A

Surely this opcode expects children (two 64-bit integers).

IL Opcode Properties

N/A

I would think the opcode should have properties similar to lmul and iumul.

Node flags

is64Bit

I don't think is64Bit is a node flag.

lumul would perform multiplication between two unsigned long integers and store the result in a register.

Pedantic: the opcode wouldn't actually "store" a result, it just emits (returns) a result as a 64-bit integer.

IL Validation

Via tril tests.

This section is supposed to cover special considerations regarding the IL Validator (e.g. special handling in existing validation rules or entirely new rules needed). I believe lumul should be covered by the existing rules and won't require any special handling.

[hsoontie]

I updated it for clarity. Thank you!
Are there specific points that should be listed under properties, and if so, where may I find them?

[andrewcraik]

So given that multiplication is repeated addition the signed-ness of the operand types does not affect the low half of the result. So an imul applies to both signed and unsigned integers because the result produces is the low 32-bits and behavior on overflow is undefined. We have an imulh and an iumulh to represent the high half of a 32bit multiply which does vary based on signedness. As a result, the iumul is deprecated as is iuadd et al. The same principle applies to lmul. This means that lmul is signless and we need an lmulh and lumulh if we don't already have them. If you care about overflow the signed ness of the operation is implicit in the use of either OverflowCHK or UnsignedOverflowCHK but the overflow check evaluators generally need to specially handle the evaluation of their children to ensure that they test the correct flags etc. As a result I don't think adding an lumul is appropriate.

[andrewcraik]

Given the above I believe this opcode request should be closed - lmul is without sign and serves to evaluate the cases covered by the proposed lumul.

[Leonardo2718]

Upon reflection, I think @andrewcraik is correct. Although there is an iumul opcode, it should be deprecated because it is equivalent to imul (overflow checks are not represented/handled by these opcodes). There is, therefore, no need to make the lmul family of opcodes symmetric with the 32-bit counterparts by adding lumul.

Closing.