[PATCH] D110867: X86InstrInfo: Support immediates that are +1/-1 different in optimizeCompareInstr

Thu Oct 14 02:51:52 PDT 2021

RKSimon added inline comments.

================
Comment at: llvm/lib/Target/X86/X86InstrInfo.cpp:4494
+      case X86::COND_L: // x <s (C + 1)  -->  x <=s C
+        if (ImmDelta != 1 || CmpValue == INT64_MIN >> Shift)
+          return false;
----------------
foad wrote:
> MatzeB wrote:
> > MatzeB wrote:
> > > foad wrote:
> > > > Is it OK to use `INT64_MIN >> Shift` here? I think the standard says right shift of a negative value is implementation-defined.
> > > Good question!
> > > 
> > > I think we can rely on two-complement arithmetic shift behavior here. I'm not aware of any compiler behaving differently, certainly not the one ones specified to be used for LLVM in the documentation: https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library
> > > 
> > > Other code like APInt seems to rely on this as well: https://github.com/llvm/llvm-project/blob/4f0225f6d21b601d62b73dce913bf59d8fb93d87/llvm/include/llvm/ADT/APInt.h#L796
> > > 
> > > That said if you have a simple alternative to this, I'd be happy to change the code...
> > How about I add this:
> > 
> > ```
> > static_assert(INT64_MIN >> 16 == INT32_MIN && INT64_MIN >> 24 == INT8_MIN,
> >               "expects compiler with twos complement right shift");
> > ```
> > 
> > and then whoever has a whacky compiler will see the problem and can go fix it.
> I was mostly worried a buildbot with the "undefined behaviour" sanitiser complaining about it -- though I'm not actually sure if ubsan detects this by default.
> 
> I don't really mind what fix you use, if any. The static_assert sounds fine to me. Alternatively you could rewrite the expression, e.g. as `~(INT64_MAX >> Shift)`, but it's much less obvious what it means.
What about using APInt? 

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110867