[
https://issues.apache.org/jira/browse/LUCENE-5856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080818#comment-14080818
]
Yonik Seeley commented on LUCENE-5856:
--------------------------------------
bq. It is interesting why Hotspot oitsself does not remove the & in our code
during optimization.
Indeed. I just tested if I should make the corresponding changes in
heliosearch's native code, but both gcc and llvm(clang) did this optimization
with -O or above. That's good since C/C++ standards leave shifting by an
amount outside 0..63 as undefined.
> remove useless & 0x3f from *BitSet.get and company
> --------------------------------------------------
>
> Key: LUCENE-5856
> URL: https://issues.apache.org/jira/browse/LUCENE-5856
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Robert Muir
> Fix For: 5.0, 4.10
>
> Attachments: LUCENE-5856.patch
>
>
> java specification says:
> {quote}
> If the promoted type of the left-hand operand is long, then only the six
> lowest-order bits of the right-hand operand are used as the shift distance.
> It is as if the right-hand operand were subjected to a bitwise logical AND
> operator & (ยง15.22.1) with the mask value 0x3f (0b111111). The shift distance
> actually used is therefore always in the range 0 to 63, inclusive.
> {quote}
> and x86 works the same way.
> if we remove this, we just see less instructions with printassembly...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
