similar to: [LLVMdev] overflow + saturation stuff

Chris Lattner wrote: > On Feb 8, 2009, at 5:54 PM, Paul Schlie wrote: >> Are overflow behavior tags meant to enable the specification of a >> particular instruction's required or presumed overflow behavior? > > I'm not sure what you mean. The overflow tags specify what happens if > overflow happens (defined wrapping, defined saturating, or undefined > behavior),

Hi, it's my first time to write a loop with R for my homework. This loop is part of the function. I wanna assign values for hll according to panel [ii,1]=pp. I didn't get any error message in this part. but then when I further calculate another stuff with hll, the function can't return. I think it must be some problem in my loop. Probably something stupid or easy. But I tried to look

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 -Chris

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

Hi Daniele and Arnaud, While tracking down the Cyber Power voltage scaling issue, I found the DDL repository extremely helpful. Instead of searching across all of the old mailing list posts, I was able to run 'git grep' in the Cyber Power directory, and the consistency of the data made it an easy task. I had a motherboard failure on my main computer, and I was trying to recreate the

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

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

Further, with respect to proposed rotate operations, as with add's etc. carry semantics; all forms of shift/rotate may be specified with a single shift instruction with a tag specifying the source of in-shift bits (being that shifted out, dup, or 0); if an operation's tag is meant to affect the semantics of the specified operation.

On Feb 8, 2009, at 11:33 AM, Chris Lattner wrote: > > 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

On 08 Feb 2009, at 14:41, Gordon Henriksen wrote: > On 2009-02-08, at 05:59, Jonas Maebe wrote: > >> The proposal suggests to change/split the existing sub/add/mul >> opcodes. This makes me wonder to what extent it is (currently, or >> ever) advisable for an external compiler to generate LLVM IR. Is >> there a plan to stabilise at some point and guarantee backwards

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

On 2009-02-08, at 05:59, Jonas Maebe wrote: > The proposal suggests to change/split the existing sub/add/mul > opcodes. This makes me wonder to what extent it is (currently, or > ever) advisable for an external compiler to generate LLVM IR. Is > there a plan to stabilise at some point and guarantee backwards > compatibility to a certain extent, or should compilers that are

I am interested in using LLVM to translate C and C++ into high-level language code. (As an update to an earlier project of mine, Clue, which used the Sparse compiler library to do this: it targets Lua, Javascript, Perl 5, C, Java and Common Lisp, with a disturbing amount of success. See http://cluecc.sourceforge.net for details.) The obvious place to start on this is the C backend, except in

> Is this the current layout? > > nut-website (branch: dll-hll) > \__ nut submodule (branch: master) > \__ ddl submodule (branch unknown?) nut-website (branch: dll-hll) \__ nut submodule (branch: master @ abc0006 [not updated to avoid conflicts when merging back to master]) \__ ddl submodule (branch: master @ bbfd79f; now updated to ab6166c) > The "ddl" branch

On Jan 24, 2011, at 2:01 PM, David Given wrote: > I am interested in using LLVM to translate C and C++ into high-level > language code. (As an update to an earlier project of mine, Clue, which > used the Sparse compiler library to do this: it targets Lua, Javascript, > Perl 5, C, Java and Common Lisp, with a disturbing amount of success. > See http://cluecc.sourceforge.net for

The attached file contains build files for TI's Code Composer Studio (CCS) for the C54x, C55x, and C6x DSPs. I had intended to post this a couple of months ago, but it took a long time to get around to doing the little bit of cleanup required. This is a file I/O loopback application suitable for running with the CCS simulators, for evaluating memory and MIPs requirements for these

David Given <dg at cowlark.com> writes: > The obvious place to start on this is the C backend, except in these 2.8 > days the C backend is so hedged about with caveats I'm rather wary of > basing anything on it. I also recall seeing comments here that it's due > for a rewrite from scratch, and that various people were looking into > it. Can anyone go into more detail

Thank you for reminding me the notion of the basic block. Of course, I know all the assembly takes the form of BBs and is divided into units of BB. OK. It looks better for me to explain what I wanted to do more clear from the first. Actually, I am working on emitting out an assembly of VM by using LLVM. LLVM assembly looks similar with this VM assembly except BB. The VM assembly does not have the

Hi all, The patches linked below introduce a new family of intrinsics, for integer saturation: @llvm.usat, and @llvm.ssat (unsigned/signed). Quoting the added documentation: %r = call i32 @llvm.ssat.i32(i32 %x, i32 %n) is equivalent to the expression min(max(x, -2^(n-1)), 2^(n-1)-1), itself implementable as the following IR: %min_sint_n = i32 ... ; the min. signed integer of