[llvm-commits] [PATCH] Bug 5207: make APInt trunc(), sext(), zext() return a new value

[Jay Foad]

http://llvm.org/bugs/show_bug.cgi?id=5207

The bug says:

> The APInt API is extremely inconsistent.  Among other things, some methods
> update the APInt in place, and some return a new APInt.  This leads to awful
> stuff like:
>
>     V = V.lshr(ByteStart*8);
>     V.trunc(ByteSize*8);

The attached patch changes APInt methods trunc(), sext(), zext(),
sextOrTrunc() and zextOrTrunc(), and APSInt methods extend(),
extOrTunc() and new method trunc(), to be const and to return a new
value instead of modifying the object in place. I think this makes for
clearer code.

This introduces assignments in some places where they weren't needed
before, e.g.:

-    Result.zext(BitWidth);
+    Result = Result.zext(BitWidth);

However, many places already explicitly constructed a temporary, and
they look much cleaner now, e.g.:

-      APInt ThisVal = APInt(OpVal).trunc(DstBitSize);
+      APInt ThisVal = OpVal.trunc(DstBitSize);

I understand there may be efficiency concerns, because there will be
more memory allocation going on when manipulating values more than 64
bits wide. I'm happy to try to measure the impact if you can suggest
how to do this.

It passes "make check-all" when LLVM is configured --without-llvmgcc
--without-llvmgxx.

I think the llvm-gcc front end changes are fairly straightforward, but
I haven't been able to test them (see
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-December/012408.html).

OK to commit?

Thanks,
Jay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: truncext2.diff
Type: text/x-patch
Size: 68261 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101203/55fc5166/attachment.bin>