[llvm-dev] multiprecision add/sub

Manuel Jacob via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 15 15:38:41 PST 2017


On 2017-02-15 23:59, David Majnemer via llvm-dev wrote:
> On Wed, Feb 15, 2017 at 2:28 PM, Stephen Canon via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> 
>> On Feb 15, 2017, at 2:22 PM, Bagel via llvm-dev 
>> <llvm-dev at lists.llvm.org>
>> wrote:
>> 
>> > I suggest that LLVM needs intrinsics for add/sub with carry, e.g.
>> >
>> >  declare {T, i1} @llvm.addc.T(T %a, T %b, i1 c)
>> >
>> > The current multiprecision clang intrinsics example:
>> >  void foo(unsigned *x, unsigned *y, unsigned *z)
>> >  { unsigned carryin = 0;
>> >    unsigned carryout;
>> >    z[0] = __builtin_addc(x[0], y[0], carryin, &carryout);
>> >    carryin = carryout;
>> >    z[1] = __builtin_addc(x[1], y[1], carryin, &carryout);
>> >    carryin = carryout;
>> >    z[2] = __builtin_addc(x[2], y[2], carryin, &carryout);
>> >    carryin = carryout;
>> >    z[3] = __builtin_addc(x[3], y[3], carryin, &carryout);
>> >  }
>> > uses the LLVM intrinsic "llvm.uadd.with.overflow" and generates
>> > horrible code that doesn't use the "adc" x86 instruction.
>> >
>> > What is the current thinking on improving multiprecision arithmetic?
>> 
>> Why do you think this requires new intrinsics instead of teaching the
>> optimizer what to do with the existing intrinsics?
>> 
> 
> In general, it is harder to reason about memory. Also, you are forced 
> to
> allocate memory for the carryout even if you are not interested in 
> using it.

While the clang builtins access memory conceptually, similar to every 
variable access in C, this is removed by mem2reg.  The optimizer doesn't 
have to reason about memory in the example after mem2reg was run.

> 
> 
>> 
>> – Steve
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list