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
OK. Thanks very much. By the way, does anybody know which part of the llvm source code (or clang source code) handle this situation? Because I want to dig deeper and know how to handle this more detail. Best Regards Wu Zhao At 2015-02-02 22:30:07, "Jaak Randmets" <jaak.ra at gmail.com> wrote:>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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/54bb428b/attachment.html>
Wider-than-legal types are not necessarily handled as vectors. On x86, something like i128 is handled, within limitations, using multiple non-vector instructions. e.g. adding i128 lowers to ADD followed by ADC. Things I've noticed: - The x86 lowering does not generate loops even in cases where they might be reasonable. If you add two i2048 values, then you'll get 32 64-bit adds, unrolled. - Some ops are not supported, e.g. multiplying two i128 will result in a crash. However, i128 x i128 seems to work. In general, you can probably rely on the DAG legalization to generate correct code for values twice as wide as your processor can reasonably handle (e.g. i128 for x64_64) and you're best to steer clear of anything larger. Use GMP or roll your own for those cases. On Mon, Feb 2, 2015 at 9:30 AM, Jaak Randmets <jaak.ra at gmail.com> wrote:> 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 > _______________________________________________ > 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/5d92f8a5/attachment.html>
On 2/2/2015 8:04 PM, Wu Zhao wrote:> OK. Thanks very much. By the way, does anybody know which part of the > llvm source code (or clang source code) handle this situation? Because > I want to dig deeper and know how to handle this more detail.Perhaps this will be useful to start looking inside LLVM: http://llvm.org/docs/CodeGenerator.html#selectiondag-legalizetypes-phase SelectionDAG LegalizeTypes Phase The Legalize phase is in charge of converting a DAG to only use the types that are natively supported by the target. Sameer. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150203/149208ad/attachment.html>