Hi everyone!
Here, I have a question and am curious about i128. I want to know how the
LLVM handle i128, because many compiler backend doesn't support i128
directly. So I am very curious and want to how the llvm handle this situation?
Besides i128, such as i256, i512, even i24? Thanks.
Best Regards
Wu Zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/74395a81/attachment.html>
Big data types corresponds to its equivalent vector types, for example, 16 x i8, 8 x i16, 4 x i32 etc. Cheers, Erkan. On Mon, Feb 2, 2015 at 2:49 PM, Wu Zhao <bluechristlove at 163.com> wrote:> Hi everyone! > Here, I have a question and am curious about i128. I want to know how > the LLVM handle i128, because many compiler backend doesn't support i128 > directly. So I am very curious and want to how the llvm handle this > situation? Besides i128, such as i256, i512, even i24? Thanks. > > > Best Regards > > Wu Zhao > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Best Regards, Erkan Diken ------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/7bd61c51/attachment.html>
I asked a similar question last year here <http://stackoverflow.com/questions/22255634/llvm-arbitrary-precision-integer>. Operations on types iN with no direct translation into one assembly instruction seem to be translated into several ones correctly. 2015-02-02 14:49 GMT+01:00 Wu Zhao <bluechristlove at 163.com>:> Hi everyone! > Here, I have a question and am curious about i128. I want to know how > the LLVM handle i128, because many compiler backend doesn't support i128 > directly. So I am very curious and want to how the llvm handle this > situation? Besides i128, such as i256, i512, even i24? Thanks. > > > Best Regards > > Wu Zhao > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/d2541bbf/attachment.html>
For 64-bit X86 code we have had good success with using up-to 128-bit integers (this includes say 36-bit or even 2-bit integers). On Mon, Feb 2, 2015 at 4:03 PM, Alejandro Velasco <gollumdelperdiguero at gmail.com> wrote:> I asked a similar question last year here. Operations on types iN with no > direct translation into one assembly instruction seem to be translated into > several ones correctly. >In my experience this is *definitely* not true in practise, at least on x86. Using larger than 128-bit integers we have hit assertion failures, crashes and miscompiles. Things are even worse for vectors of non-legal(?) types (say <2 x i2>). Some of the issue that we hit after giving up on vectorized code and relying directly on LLVM for wider-than-legal types: http://llvm.org/bugs/show_bug.cgi?id=20011 (crash with <2 x i2>) http://llvm.org/bugs/show_bug.cgi?id=20012 (error when storing <2 x i4>) http://llvm.org/bugs/show_bug.cgi?id=19797 (assert failure on multiplication of i192) http://llvm.org/bugs/show_bug.cgi?id=20921 (assert failure on stores and loads of i193) http://llvm.org/bugs/show_bug.cgi?id=21184 (miscompilation of wider-than-legal types) I would *really* wish that the documentation made sure to mention, that wider-than-legal types are not expected to work. - Jaak