On Jun 13, 2007, at 12:06 PM, Lauro Ramos Venancio wrote:
>> I don't think this is appropriate Lauro. The program needs to be
>> fixed, it's not just a codegen or optimizer issue, everything in the
>> compiler assumes that these shifts are undefined. Programs cannot
>> reliably expect a compiler to do the right thing here, and your patch
>> isn't a fix.
>
> Nowadays LLVM doesn't assume, in all places, that these shifts are
> undefined.
> See the following code (APInt.cpp):
>
> // If all the bits were shifted out, the result is 0. This avoids
> issues
> // with shifting by the size of the integer type, which produces
> undefined
> // results. We define these "undefined results" to always be 0.
> if (shiftAmt == BitWidth)
> return APInt(BitWidth, 0);
>
> and this code:
>
> // If all the bits were shifted out, the result is, technically,
> undefined.
> // We return -1 if it was negative, 0 otherwise. We check this
> early to avoid
> // issues in the algorithm below.
> if (shiftAmt == BitWidth) {
> if (isNegative())
> return APInt(BitWidth, -1ULL);
> else
> return APInt(BitWidth, 0);
> }
>
> I think to implement the gcc behavior would make easier the migration
> from gcc to llvm.
APInt can't return undef, so it has to pick a deterministic value.
LLVM values are a different story.
-Chris
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
