RFR: 8261008: Optimize Xor

[Bernardo Sulzbach]

On Tue, 2 Mar 2021 06:38:28 GMT, Eric Liu <github.com+10482586+theRealELiu at openjdk.org> wrote:

>>> If we agree that this optimization is desired, then it makes sense to also write optimizations for `x - x` and `x | x`.
>>> 
>>> However, how often do these patterns occur in real code? Can you provide some examples (of source code from OSS projects) where `x ^ x`, `x - x`, or `x | x` occur?
>> 
>> Thanks for your feedback. I didn't find them in real cases. This case was discussed in https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-November/041798.html.
>> 
>> To persue the optimal code, it could be done without too much effort.
>
>> If we agree that this optimization is desired, then it makes sense to also write optimizations for `x - x` and `x | x`.
>> 
>> However, how often do these patterns occur in real code? Can you provide some examples (of source code from OSS projects) where `x ^ x`, `x - x`, or `x | x` occur?
> 
> Hi Bernardo,
> 
> I tried to find this by adding some instruments. 
> 
> The JDK itself exactly has this pattern. 
> 
> Current thread (0x0000fffedc3f9130):  JavaThread "C2 CompilerThread3" daemon [_thread_in_native, id=3972, stack(0x0000fffecfa00000,0x0000fffecfc00000)]
> 
> 
>  Current CompileTask:
>  C2:   2687 1278       4       jdk.tools.jlink.internal.ImageFileCreator$$Lambda$127/0x00000008000ed3b0::accept (15 bytes)
> 
>  Stack: [0x0000fffecfa00000,0x0000fffecfc00000],  sp=0x0000fffecfbf9d70,  free space=2023k
>  Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>  V  [libjvm.so+0x5eb314]  XorINode::Value(PhaseGVN*) const+0x134
>  V  [libjvm.so+0x128a5b0]  PhaseIdealLoop::split_thru_phi(Node*, Node*, int)+0x1d0
>  V  [libjvm.so+0x128d7a4]  PhaseIdealLoop::split_if_with_blocks_pre(Node*)+0x2b4
>  V  [libjvm.so+0x128f360]  PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&)+0x160
>  V  [libjvm.so+0x1283280]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0xf50
>  V  [libjvm.so+0x9cfadc]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x28c
>  V  [libjvm.so+0x9cd21c]  Compile::Optimize()+0xf3c
>  V  [libjvm.so+0x9ce580]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0xf50
>  V  [libjvm.so+0x80ddbc]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x178
>  V  [libjvm.so+0x9de684]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x9d0
>  V  [libjvm.so+0x9df22c]  CompileBroker::compiler_thread_loop()+0x328
>  V  [libjvm.so+0x18bac90]  JavaThread::thread_main_inner()+0x37c
>  V  [libjvm.so+0x18c1a78]  Thread::call_run()+0xf8
>  V  [libjvm.so+0x149ac60]  thread_native_entry(Thread*)+0x120
>  C  [libpthread.so.0+0x7088]  start_thread+0xb0
> 
> I think no one would write those kind of code directly, but GVN, after all, was a general phase which may create new node during  several iteration. Besides the inline method may lead to this as well.
> 
> --Eric

@theRealELiu that's a very interesting find!

It makes me wonder if these aren't also warnings analysis tools should provide (if it's caused by optimizations of user code), something like "expression is always 0".

-------------

PR: https://git.openjdk.java.net/jdk/pull/2776