search for: addinst

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 AddInstruction::UndefinedUnsigned: // ... } } } with this: switch (I->getOpcode()) { case Instruction::Add: // ... case Instruction::SAdd_Open...

...d. This also interacts with FP rounding mode stuff, which I expect to handle the same way with FP operations some day. > Compare this: > > switch (I->getOpcode()) { > case Instruction::Add: { > switch (cast<Add>(I)->getOverflowBehavior()) { > case AddInstruction::Wrapping: > // ... > case AddInstruction::UndefinedSigned: > // ... > case AddInstruction::UndefinedUnsigned: Sure, that is ugly. However, I think it would be much more common to look at these in "isa" flavored tests than switches: if...

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, I have a question about the llvm passes. I'm iterating over a basicblock and I can get an instruction and print it. Now, I want to iterate over the instruction and be able to modify the values of the instruction. For example, if my instruction is an add "<result> = add i32 4, %var" I want to transform it in a sub "<result> = sub i32 4, %var". I looked up

...king debug info become special metadata with special encoding properties. How special does it have to be to be labeled "first-class"? IMO, the label makes sense here: custom C++ type, bitcode, assembly, uniquing, and ownership. Doesn't seem any less "special" than, say, `AddInst`, but I don't really care what we call it. Have I missed your point? (Are you suggesting metadata is inherently second-class? How so?) > Note, I'm actually ok with us having special metadata that has special encoding properties. But if we're going that route, I don't think th...

Hello LLVM community, For testing IR passes, LLVM currently has two kinds of tests: 1. regression tests (in llvm/test); .ll files invoking opt, and matching its text output using FileCheck. 2. unittests (in llvm/unittests); Google tests containing the IR as a string, constructing a pass pipeline, and inspecting the output using code. I propose to add an additional kind of test, which I call

I've attached a preliminary patch for `MDLocation` as a follow-up to the RFC [1] last week. It's not commit-ready -- in particular, it squashes a bunch of commits together and doesn't pass `make check` -- but I think it's close enough to indicate the direction and work toward consensus. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-October/077715.html IMO, the files to