RFR: 8255550: x86: Assembler::cmpq(Address dst, Register src) encoding is incorrect

Aleksey Shipilev shade at openjdk.java.net
Thu Oct 29 06:20:43 UTC 2020


On Wed, 28 Oct 2020 23:10:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Compare:
>> 
>> void Assembler::cmpq(Address dst, Register src) {
>>   InstructionMark im(this);
>>   emit_int16(get_prefixq(dst, src), 0x3B);
>>   emit_operand(src, dst);
>> }
>> 
>> void Assembler::cmpq(Register dst, Address src) {
>>   InstructionMark im(this);
>>   emit_int16(get_prefixq(src, dst), 0x3B);
>>   emit_operand(dst, src);
>> }
>> 
>> They use the same opcode -- `0x3B`, which is for `CMP r, r/m`. While `cmpq(Address,Register)` actually should be using `0x39` for `CMP r/m, r`. I also suspect they emit basically the same instruction, because the `get_prefixq` and `emit_operand` argument order is irrelevant.
>> 
>> AFAIU, it does not break horribly, because the `cmpq(Address,Register)` is not used anywhere except the new code in `MacroAssembler::safepoint_poll`, added by [JDK-8253180](https://bugs.openjdk.java.net/browse/JDK-8253180). This was found by Zhengyu, when he tried to enable that new code on x86_32 by inverting `cmpq(addr, reg); jcc(above, slow_path)` to `cmpptr(reg, addr); jcc(belowEquals, slow_path)`. Then, everything blew up, because the semantics of `cmpq(addr,reg)` was wrong, and this inversion was subtly broken.
>> 
>> Current candidate patch encodes this `cmpq` properly. Since that changes the semantics, I had to flip the condition code in its only use. I opted to do this, because _maybe_ some code in downstream projects want to use this odd `cmpq`. Although even if so, the uses could be trivially rewritten.
>> 
>> Alternatives:
>>  - I considered removing `cmpq(Address,Register)` altogether, but it would require more work to untangle `cmpptr(Address,Register)` and `cmpptr(Address,AddressLiteral)` for x86_32. 
>>  - We can also split out `MacroAssembler::safepoint_poll` change to use `cmpq(Register,Address)` to begin with, but current shape gives us a way to test the encoding.
>> 
>> Additional testing:
>>  - [x] tier1 with Shenandoah (a few failures are pre-existing)
>>  - [x] tier1 with Z (AFAICS, all failing tests are OOME'ing or break SA, and probably are problem-listed)
>
> Good.

Thanks for review @vnkozlov and @sviswa7!

@fisk, does the changed code in `safepoint_poll` still looks good for you?

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

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


More information about the hotspot-dev mailing list