JDK-8214027 : Reinstate testB_mem_imm pattern in x86_64.ad
- Type: Enhancement
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 12
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: x86_64
- Submitted: 2018-11-18
- Updated: 2020-10-06
- Resolved: 2018-11-18
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 12 |
|---|
12 b21Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
The current fix for JDK-8213473 replaces 'testB_mem_imm' with 'testUB_mem_imm' in 'x86_64.ad' which is fine for unsigned bytes, for example: if ((flags & 0x80) != 0) ... But per JLS ��5.6.2 & ��5.1.2, if we have something like: if ((flags & (byte)0x80) != 0) ... the mask is 32-bit sign-extended and 'LoadB' isn't converted to 'LoadUB' in 'AndINode::Ideal' which is fine. Unfortunately 'testUB_mem_imm' won't be matched in this case, so I guess we'd need both 'testB_mem_imm' & 'testUB_mem_imm' patterns.
Comments
|