search for: bedifficult

It takes two "llvm.uadd.with.overflow" instances to model the add-with-carry when there is a carry-in. Look at the IR generated by the example. I figured that the optimization of this would bedifficult (else it would have already been done :-)). And would this optimization have to be done for every architecture? On 02/15/2017 04:28 PM, Stephen Canon wrote: > > Why do you think this requires new intrinsics instead of teaching the optimizer what to do with the existing intrinsics? > &g...

On 02/16/2017 12:08 PM, Stephen Canon wrote: >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com >> <mailto:bagel99 at gmail.com>> wrote: >> >> I figured that the optimization of this would bedifficult (else it would >> have already been done :-)) > > Don’t make this assumption. There’s lots of opportunities for optimization > scattered around. Some of them are left because they’re genuinely difficult, > but most either simply haven’t been noticed by anyone, or are known but si...

...ephen Canon wrote: > >> On Feb 16, 2017, at 9:12 AM, Bagel <bagel99 at gmail.com <mailto:bagel99 at gmail.com> > >> <mailto:bagel99 at gmail.com <mailto:bagel99 at gmail.com>>> wrote: > >> > >> I figured that the optimization of this would bedifficult (else it would > >> have already been done :-)) > > > > Don’t make this assumption. There’s lots of opportunities for optimization > > scattered around. Some of them are left because they’re genuinely difficult, > > but most either simply haven’t been noticed by any...

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],