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

Matthias Braun via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 14 11:01:42 PDT 2021


MatzeB 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;
----------------
RKSimon wrote:
> 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? 
> What about using APInt? 

Seemed a bit overengineered given the value fits neatly in an uint64_t, but sure I will change it to use an APInt then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110867



More information about the llvm-commits mailing list