Skip to content
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

Add bitpermute opcode #2156

Merged
merged 1 commit into from
Dec 20, 2017
Merged

Conversation

ncough
Copy link

@ncough ncough commented Dec 18, 2017

This change adds a new opcode, bitpermute, with 8, 16, 32 and 64 bit variants.

The opcode takes a value and an array of bit indices. It then constructs a new value, of the same width as the original, by extracting bits at these indices in the original value and placing them in the lower bits of the result, corresponding to their position in the bit index array. Unspecified bits are zeroed. This calculation can be expressed as:

result = 0
for (x = 0; x < length; ++x)
  result |= ((value >> indices[x]) & 1) << x
return result

The node has three children:

  • the value, which should be an 8, 16, 32 or 64 bit integer, matching the opcode's result
  • the address of the byte array
  • the array's length, as a 32 bit integer

The opcode is specified using shifts, rather than bit numbering, to remain consistent across platforms. Similar to the shift operations, the behaviour for bit indices greater the width of the value is undefined. This affects both indices in the byte array greater than the width and if the number of specified bits, the array length, exceeds the width of the result.

This change includes an X86 implementation, which consists of a series of bit tests and sets. The current implementation has an optimization for constant length arrays, a common case under JProfiling.

@ncough
Copy link
Author

ncough commented Dec 18, 2017

@0dvictor Could you please review the X86 implementation?

@ncough
Copy link
Author

ncough commented Dec 18, 2017

@fjeremic You may be interested in a Z implementation of this operation to improve JProfiling performance.

@@ -228,8 +228,7 @@ namespace ILProp2
ZeroExtension = 0x01000000,
SignExtension = 0x02000000,
ByteSwap = 0x04000000,
// Available = 0x08000000,
// Available = 0x10000000,
BitPermute = 0x08000000,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to have deleted the 0x10000000 available line. We should leave that line in so others can use it. Otherwise a glossing eye may overlook that we jump from 0x08000000 to 0x20000000

Also why do we need this flag exactly? Doesn't the IL imply this already?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this was an accidental removal carried over from another set of changes.

The flag was added in an attempt to mirror ByteSwap's changes as a template for adding an opcode. Neither of the opcodes seem to make use of if. I'll remove BitPermute.

@Leonardo2718
Copy link
Contributor

Any chance of getting 8 and 16-bit variants? Maybe not as part of this PR, but could you open an issue about it? 🙂

@ncough ncough force-pushed the jprofilingInstruction branch 4 times, most recently from 1458d3e to 5674d61 Compare December 19, 2017 15:34
@ncough
Copy link
Author

ncough commented Dec 19, 2017

8-bit and 16-bit variants have been added.

@andrewcraik
Copy link
Contributor

looks reasonable to me

@0dvictor
Copy link
Contributor

Looks good to me.

@ncough
Copy link
Author

ncough commented Dec 19, 2017

I have added TRIL tests for the new opcodes, which should help in keeping behaviour consistent across the platforms.

@ncough ncough force-pushed the jprofilingInstruction branch 2 times, most recently from d23e71c to 781c616 Compare December 19, 2017 22:25
@0xdaryl
Copy link
Contributor

0xdaryl commented Dec 20, 2017

Huge thumbs up for the Tril tests. Great addition @ncough !

@fjeremic
Copy link
Contributor

Huge thumbs up for the Tril tests. Great addition @ncough !

This should set a precedent for any new IL to be added to OMR. IMO all new IL must come with a fairly exhaustive Tril test suite and full documentation. Awesome work @ncough! Thanks for your contribution.

Copy link
Contributor

@Leonardo2718 Leonardo2718 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests look great! Awesome job @ncough 👍

@vijaysun-omr
Copy link
Contributor

genie-omr build all

Copy link
Contributor

@0xdaryl 0xdaryl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor suggestions only.

@@ -1023,6 +1023,17 @@ OMR::CodeGenerator::getSupportsIbyteswap()
return false;
}

/**
* Query whether ibitpermute and lbitpermute are supported
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be: "whether [bsil]bitpermute IL opcodes are supported" ? It covers more than just i and l.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this was missed with the addition of the other variants. Thanks for finding it.

if (x < 8)
generateRegRegInstruction(OR1RegReg, node, resultReg, tmpReg, cg);
else
generateRegRegInstruction(ORRegReg(nodeIs64Bit), node, resultReg, tmpReg, cg);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can save some DLL code size here by generating one call with differing opcodes, something like:

TR_X86OpCodes op = (x < 8) ? OR1RegReg : ORRegReg(nodeIs64Bit);
generateRegRegInstruction(op, node, resultReg, tmpReg, cg);

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I have followed your suggestion and improved it.

@0xdaryl
Copy link
Contributor

0xdaryl commented Dec 20, 2017

genie-omr build all

This change adds a new opcode: bitpermute.
The instruction takes an original value and an
array of bit indices. It then constructs a new value
by extracting bits at these indices in the original
value and placing them in the lower bits of the
new.

Signed-off-by: Nicholas Coughlin <cnic@ca.ibm.com>
@ncough
Copy link
Author

ncough commented Dec 20, 2017

There was an issue with the disable used to limit the Tril tests according to platform, as its currently only supported on X86. This has been corrected and other platforms should be excluded. It should be noted that this does not use cg->getSupportsBitPermute() to test for support, as its not immediately obvious how to access the codegen.

@vijaysun-omr
Copy link
Contributor

genie-omr build all

@vijaysun-omr
Copy link
Contributor

Test have passed. Merging.

@vijaysun-omr vijaysun-omr merged commit bff5a5a into eclipse:master Dec 20, 2017
@fjeremic
Copy link
Contributor

There was an issue with the disable used to limit the Tril tests according to platform, as its currently only supported on X86. This has been corrected and other platforms should be excluded. It should be noted that this does not use cg->getSupportsBitPermute() to test for support, as its not immediately obvious how to access the codegen.

@ncough just to clarify this means running comptest on non-x86 platforms will result in the "Opcode not implemented" asserts once the BitPermute.cpp tests run?

@ncough
Copy link
Author

ncough commented Dec 20, 2017

@fjeremic The BitPermute.cpp tests won't be instantiated on non-x86 platforms, as they are guarded by TR_TARGET_X86, avoiding any asserts. As support for the instruction is introduced on other platforms, this test will be have to be updated.

@fjeremic
Copy link
Contributor

@fjeremic The BitPermute.cpp tests won't be instantiated on non-x86 platforms, as they are guarded by TR_TARGET_X86, avoiding any asserts. As support for the instruction is introduced on other platforms, this test will be have to be updated.

@dchopra001 FYI. You can use this as an example for Z on how to avoid VectorTest.cpp in #1941 until we have proper Tril support for platform determination.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants