[PATCH] D143471: [X86][MC][NFC] Refine code in X86MCCodeEmitter.cpp about opcode prefix

[Kan Shengchen via Phabricator via llvm-commits]

skan added a comment.

In D143471#4118152 <https://reviews.llvm.org/D143471#4118152>, @pengfei wrote:

> In D143471#4118036 <https://reviews.llvm.org/D143471#4118036>, @skan wrote:
>
>> In D143471#4117637 <https://reviews.llvm.org/D143471#4117637>, @uabelho wrote:
>>
>>> Hi,
>>>
>>> I noticed that if I run lit tests with ubsan built binaries with this patch there are many many tests failing like
>>>
>>>   ../lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:222:19: runtime error: left shift of negative value -1
>>
>> I think it's false positive?
>>
>>   ~R << 7
>>
>> `R` is an `unsigned`, so `~R` is `unsigned` too. Although the value of `~R` may be `0xffffffff`. But I remember the left shift operation on `unsigned` is always well defined as long as the shift not exceed the size of `unsigned`.
>
> I remember the `<<` operator is defined to shift signed int in C language. There's no relationship with the type of shifted value.

I am not an expert in latest C standard.  But we are in C++

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

> 8.5.7 Shift operators [expr.shift]
> 1 The shift operators << and >> group left-to-right.
> shift-expression:
> additive-expression
> shift-expression << additive-expression
> shift-expression >> additive-expression
> The operands shall be of integral or unscoped enumeration type and integral promotions are performed. The
> type of the result is that of the promoted left operand. The behavior is undefined if the right operand is
> negative, or greater than or equal to the length in bits of the promoted left operand.
> 2 The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned
> type, the value of the result is E1 × 2
> E2, reduced modulo one more than the maximum value representable in
> the result type. Otherwise, if E1 has a signed type and non-negative value, and E1 × 2
> E2 is representable
> in the corresponding unsigned type of the result type, then that value, converted to the result type, is the
> resulting value; otherwise, the behavior is undefined.

According to the rule, `unsigned` does not need to be promoted and the shift operation is still on a `unsigned`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143471/new/

https://reviews.llvm.org/D143471