[PPC64] Use INT32_MIN instead of std::numeric_limits<int32_t>::min()

[MaskRay]

Summary

D53821 fixed the bogus MSVC (at least 2017) C4146 warning (unary minus applied on unsigned type)
by using std::numeric_limits<int32_t>::min().
The warning was because -2147483648 is incorrectly treated as unsigned long instead of long long)

Let's use INT32_MIN which is arguably more readable.
Note, on GCC or clang, -0x80000000 works fine (ILP64: long, LP64: long long).

[MaskRay]

Update description

[jhenderson]

I'm honestly not really convinced that -0x80000000LL is more readable. I think it's a matter of personal taste. I think numeric_limits<int32_t>::min() is more explicit about what it's aiming to achieve. That being said, I really don't care that much, so if somebody else gives a LGTM, I don't mind.

[arichardson]

I agree with James that numeric_limits is clearer. I've run into bugs before because there was a 0/f missing when trying to use max/min value integers.

Is the problem here that we are missing a cast to int64_t?

[jhenderson]

In D54200#1289971, @arichardson wrote:

Is the problem here that we are missing a cast to int64_t?

Not sure if you're referring to the original problem, but I assume you are. The original issue was highlighting a bug in MSVC's C++11 compatibility, as the type of the (now replaced) integer literal should be a signed long long automatically (effectively an int64_t), but instead it became an unsigned int. Casting it to an int64_t explicitly would also have worked, I think.

[ruiu]

My preference is INT32_MIN which works both in C and C++, but I don't think 0x80000000 is more readable than numeric_limits<int32_t>::min(). Honestly it looks a bit more like an exercise to see if you really understand how negative numbers are represented in the two's complement, I think.

[jhenderson]

In D54200#1290042, @ruiu wrote:

My preference is INT32_MIN which works both in C and C++, but I don't think 0x80000000 is more readable than numeric_limits<int32_t>::min(). Honestly it looks a bit more like an exercise to see if you really understand how negative numbers are represented in the two's complement, I think.

I have no objection to INT32_MIN, as it's clear as to the purpose.

[MaskRay]

Use INT32_MIN

[sfertile]

LGTM

lld/trunk/ELF/Arch/PPC64.cpp

bool PPC64::adjustPrologueForCrossSplitStack(uint8_t *Loc, uint8_t *End,
   if (!CheckRegOperands(FirstInstr, 12, 1))
     return false;
   if (SecondInstr != 0x60000000 && !CheckRegOperands(SecondInstr, 12, 12))
     return false;
 
   int32_t StackFrameSize = (HiImm * 65536) + LoImm;
   // Check that the adjusted size doesn't overflow what we can represent with 2
   // instructions.
-  if (StackFrameSize <
-      std::numeric_limits<int32_t>::min() + Config->SplitStackAdjustSize) {
+  if (StackFrameSize < Config->SplitStackAdjustSize + INT32_MIN) {
     error(getErrorLocation(Loc) + "split-stack prologue adjustment overflows");
     return false;
   }
 
   int32_t AdjustedStackFrameSize =
       StackFrameSize - Config->SplitStackAdjustSize;
 
   LoImm = AdjustedStackFrameSize & 0xFFFF;