similar to: [LLVMdev] overflow + saturation stuff

Hi Chris, Would it be better to split add into multiple opcodes instead of using SubclassData bits? Compare this: switch (I->getOpcode()) { case Instruction::Add: { switch (cast<Add>(I)->getOverflowBehavior()) { case AddInstruction::Wrapping: // ... case AddInstruction::UndefinedSigned: // ... case

On Feb 8, 2009, at 8:58 AM, Dan Gohman wrote: > Hi Chris, > > Would it be better to split add into multiple opcodes instead of using > SubclassData bits? No, I don't think so. The big difference here is that (like type) "opcode" never changes for an instruction once it is created. I expect that optimizations would want to play with these (e.g. convert them to

Sounds ambitious! A comprehensive, efficient trapv would be excellent. gcc's implementation seems quite incomplete, for example it fails to trap overflows in the constant folder. John Regehr

On 07 Feb 2009, at 23:17, Chris Lattner wrote: > Edwin was asking about how we should handle PR3328, how we should make > GEP respect -fwrapv etc. I wrote up some thoughts here if anyone is > interested: > http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt The proposal suggests to change/split the existing sub/add/mul opcodes. This makes me wonder to what extent it is

2009/6/10 John McCall <rjmccall at apple.com> > There's another point that hasn't been raised yet here, which is that > the > undefinedness of calling (void*) 0 is a property of C, not necessarily > of > the LLVM abstract language. I think you can make an excellent case that > the standard optimizations should not be enforcing C language semantics, > or at

On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: >> The LLVM IR opcodes Add, Sub, and Mul have been each split into >> two. Add, Sub, and Mul now only handle integer types, and three >> new opcodes, FAdd, FSub, and FMul now handle floating-point types. > > Dan, > > Wondering the reason why there is no FDiv ? FDiv already exists; div was split quite a while ago. Dan

----- Original Message ----- From: "Dan Gohman" <gohman at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, June 16, 2009 7:49 AM Subject: Re: [LLVMdev] Upcoming API change: FAdd, FSub, FMul > > On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: > >>> The LLVM IR opcodes Add, Sub, and Mul have been each split

There's another point that hasn't been raised yet here, which is that the undefinedness of calling (void*) 0 is a property of C, not necessarily of the LLVM abstract language. I think you can make an excellent case that the standard optimizations should not be enforcing C language semantics, or at least should allow such optimizations to be disabled. Case in point —

Are there best practices regarding how to express saturation arithmetic in LLVM IR? In particular I want to make sure the IR translates efficiently to (SSE) vector instructions when executed in a simple loop. My first thought was to implement this naively by zero extending and branching on the minimum and maximum values. However, I'm also aware of branchfree alternatives[1]. Do the current

I've started hacking up a branch with a rough implementation of equality saturation. This needs me to add objects such as PEGBasicBlock, PEGInstruction, PEGTerminatorInstruction, etc. (PEG stands for "program expression block"). I wish to share most of the infrastructure that exists - I believe this is already done with Machine*. How do I do this for PEGs? I'd also like to get

Frank Lorenz a ?crit : > And yes, the same "overflow" happens even when I disable Blackfin ASM > optimizations. Indeed, that shouldn't happen. Just to make sure I understand, so far there's two problems: 1) DIV32_16() in Blackfin assembly causes problems 2) The resampler overflows When you fix/workaround those two, is the encoder/decoder working correctly or are there

Any news for this problem. Who has this problem Why you don't answer. --- En date de?: Jeu 21.10.10, ALAEDDINE abbech <alasupcom at yahoo.fr> a ?crit?: De: ALAEDDINE abbech <alasupcom at yahoo.fr> Objet: thousands Hangup per second /saturation of bandwidth ?: asterisk-users at lists.digium.com Date: Jeudi 21 octobre 2010, 11h42 Hello, I have a problem of saturation of

Hello group, Can someone please put me through how to estimate the nuisance parameters (Saturation parameter and radius) for the Geyer saturation process? It seems quite confusing to me how these parameters are achieved, but they are very important in determining the interaction between points in a point process. I am using Spatstat package. Thanks. neba [[alternative HTML version deleted]]

Hello all, I have an older machine with an AGP GeForce N6600 Nvidia card. I recently bought a new colour calibrated monitor to replace an old CRT and I've since noticed a stark difference in the colour produced by the N6600 and my newer machines with series 5 and 7 graphics cards. The newer cards show similar B+W contrast, but colour is much less saturated on the N6600. I had been

To estimate saturation binding parameters Bmax and Kd in a receptor saturation binding experiment, I use the following nonlinear equation and the nls() function: bmax*X*dummy ------------ + ns*X + background = total binding kd+X where X is concentration, and dummy is an indicator to allow shared estimation of the nonspecific binding parameter ns. This equation describes two fitted

On Fri, Jun 17, 2011 at 3:08 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi all, > > I'm proposing integer saturation intrinsics. > > def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; > def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; > > The first operand is the integer value

Thanks for the response. Should I create a small prototype of equality saturation as an LLVM pass so that there can be some concrete discussion on this? I'd love pointers. Thanks, Siddharth On Wed 6 Sep, 2017, 23:35 John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Equality saturation is very cool work and Ross Tate mentioned to me that > he'd be happy to chat

Are overflow behavior tags meant to enable the specification of a particular instruction's required or presumed overflow behavior? If a required overflow behavior, then it follows that the target must correspondingly implement the behavior; neither natively or emulated? If a presumed overflow behavior, is the target meant to preferably implement or emulate the same; or is it merely meant to

Hi Jean-Marc, I use the resampler to convert various sampling frequencies to 48 kHz on my Blackfin platform (fixed-point) 48K -> 16K speex -> 48K chain does not sound very good compared to plain 16K. But the main issue is when processing loud signals, I have truncation (and not clipping/saturation) I could hear it and see it with various music and speech messages. See example.png. I also

> -----Message d'origine----- > De : Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca] > Envoy? : lundi, 15. juin 2009 01:30 > ? : Stephane Lesage > Cc : speex-dev at xiph.org > Objet : Re: [Speex-dev] Resampler saturation, blackfin performance > > - are there buffers who could be placed in scratch memory ? > > (I don't see any speex_scratch_alloc