search for: saddo

Hi, Here is the next iteration of the patch. The only comment not addressed is this one: > It would be better to implement a target-independent check for > overflow for the "Legal" case (like how SADDO does). Hacker's > Delight > has some hints on how to do this. It's not easy for the signed case, > but is do-able. It can be lowered to a division + a branch, so it would be inefficient, plus it would be a lot of work to implement it correctly (for me at least). I was subscribed...

Hi, The attached patch implements sub.ovf/mul.ovf intrinsics similarly to the recently added add.ovf intrinsics. These are useful for implementing some vm instructions like sub.ovf/mul.ovf in .NET IL efficiently. sub.ovf is supported in target independent lowering and on x86, while mul.ovf is only supported in the x86 backend. Please review

...t;> >> Here is the next iteration of the patch. The only comment not >> addressed is this one: >> > Thanks! It's looking good. > >>> It would be better to implement a target-independent check for >>> overflow for the "Legal" case (like how SADDO does). Hacker's > Delight >>> has some hints on how to do this. It's not easy for the signed case, >>> but is do-able. >> >> It can be lowered to a division + a branch, so it would be >> inefficient, plus it would >> be a lot of work to implement...

...gmail.com> wrote: > Hi, > > Here is the next iteration of the patch. The only comment not > addressed is this one: > Thanks! It's looking good. >> It would be better to implement a target-independent check for >> overflow for the "Legal" case (like how SADDO does). Hacker's > Delight >> has some hints on how to do this. It's not easy for the signed case, >> but is do-able. > > It can be lowered to a division + a branch, so it would be > inefficient, plus it would > be a lot of work to implement it correctly (for me at...

On Tue, Dec 9, 2008 at 6:11 AM, Zoltan Varga <vargaz at gmail.com> wrote: >> It would be better to implement a target-independent check for >> overflow for the "Legal" case (like how SADDO does). Hacker's > Delight >> has some hints on how to do this. It's not easy for the signed case, >> but is do-able. > > It can be lowered to a division + a branch, so it would be > inefficient, plus it would > be a lot of work to implement it correctly (for me at...

...the next iteration of the patch. The only comment not >>> addressed is this one: >>> >> Thanks! It's looking good. >> >>>> It would be better to implement a target-independent check for >>>> overflow for the "Legal" case (like how SADDO does). Hacker's > Delight >>>> has some hints on how to do this. It's not easy for the signed case, >>>> but is do-able. >>> >>> It can be lowered to a division + a branch, so it would be >>> inefficient, plus it would >>> be a...

...he patch. The only comment not >>>> addressed is this one: >>>> >>> Thanks! It's looking good. >>> >>>>> It would be better to implement a target-independent check for >>>>> overflow for the "Legal" case (like how SADDO does). Hacker's > Delight >>>>> has some hints on how to do this. It's not easy for the signed case, >>>>> but is do-able. >>>> >>>> It can be lowered to a division + a branch, so it would be >>>> inefficient, plus it woul...

...;mul->ashr->trunc llvm.fixumul.iN(iN A, iN B, i32 Scale) = zext->mul->lshr->trunc llvm.fixsmul.sat.iN(iN A, iN B, i32 Scale) = sext->mul->ashr->ssat->trunc llvm.fixumul.sat.iN(iN A, iN B, i32 Scale) = zext->mul->lshr->usat->trunc llvm.sadd.sat.iN(iN A, iN B) = saddo->check sign&ovf->selects llvm.uadd.sat.iN(iN A, iN B) = uaddo->check ??&ovf->selects etc. The operations that the intrinsics are expressed in are strictly different anyway (sext vs zext, saddo vs uaddo etc), so there isn't any room for generalization on constant parameter...

I was browsing the dial cmd page on the wiki, and followed up to the zap channels page. There are a couple of interesting (ok, so I'm a saddo) options, specifically the "w" (wait .5 seconds before dialling the next digit) and the "c" option (You may also use the special modifier *c* to allow for clear channel connections between PRI ports) What does the "c" option do ?? Note, the "c" option is...

On 2018-08-22 05:56, John McCall via llvm-dev wrote: >> On Aug 21, 2018, at 6:20 PM, Leonard Chan <leonardchan at google.com> wrote: >> If we were to create a new type down the line, I think the main >> features that would distinguish them from other types are the >> arbitrary width and scale. Saturation can be handled through >> instructions since saturation