search for: bitpattern

...in a special order. I can do it in TableGen itself, but it will not be well maintainable based on the things I want to accomplish. Therefor, I would like to do it in the c++ file which is waaay easier (at least in the concept!!). Imagine I have this in my base class in TableGen: *bits<4> bitpattern = 0;* *let Inst{10-7} = bitpattern;* Then, at the moment that I am parsing the instruction, I would like to assign a value to "bitpattern" variable! for example: ->ParseInstruction(...) if (Mnemonic == "X") Mnemonic = getLexer().getTok().getString(); if (Mnemon...

...Cortex-A8 with VFPv3 and Advanced SIMDv1 extensions - for the encode/decode loop, described on slide 11 of the talk - for all instruction encodings with condition code AL (all 32-bit patterns with the top 4 bits set to 0xE) [1] - all silent codegen bugs[2], that is bugs where: - The reference bitpattern is defined and predictable. - The generated bitpattern is defined. - The generated bitpattern differs from the reference bitpattern. - for LLVM r156468 (updated at 2012-05-09 08:08:58 BST.) - for LLVM built with no assertions[3] Attached is a zipped copy of the full log from MC Hammer....

...2012-04-12/Slides/Richard_Barton.pdf Results -------- The below results are: - for Thumb instructions - for Cortex-A8 with VFPv3 and Advanced SIMDv1 extensions - for the encode/decode loop, described on slide 11 of the talk - all silent codegen bugs[1], that is bugs where: - The reference bitpattern is defined and predictable. - The generated bitpattern is defined. - The generated bitpattern differs from the reference bitpattern. - for LLVM r157187 (updated at 2012-05-21 14:18:06 BST.) - for LLVM built with no assertions[2] The full log from MC Hammer is very large (>16GB) this is...

...liking it! I haven't really done comprehensive testing yet—it passes all the decoding tests that the previous disassembler passed, but I'm sure there are many cases that it does not yet get right. Patches welcome. > Currently it does not provide information as to whether a particular bitpattern was UNPREDICTABLE or not. For example, an invalid bitpattern may return correct disassembly for an alternative, predictable instruction meaning that the sequence X -> disassemble -> assemble -> Y could end up with X being different to Y. Can you give an example of this? --Owen ----------...

Hi, What does llvm use for testing. The area of testing I am interested in are how to test the accuracy of the assembler/disassembler. So, if you take an IR level instruction. How do you verify that the generated CPU specific instruction is correct? Is there an automated method for this? I wish to implement automated testing on a decompiler I am writing, and thought that the test methods used in

...ined behaviour"? > > Yes, it is. I always thought these out-of-range instructions did produce an "undef" rather than allowing fully-general undefined behaviour (otherwise we couldn't speculate them, for a start). If so, I think the code ought to be valid: %1 is *some* i16 bitpattern, which means %2 cannot be completely unconstrained and should never be equal to %0. Cheers. Tim.

...it returned completely > unexpected values; I'm assuming that what is returned is an APInt > containing the bitwise representation of the floating-point value? Only two convert to integer. The convertToAPInt is unfortunately named; I'm not sure what it does but suspect it captures bitpatterns like you suggest. convertToInteger is the function I'm responsible for and it does float->int conversion according to IEEE754. If you want to place it in an APInt, create your APInt with the appropriate size and use its buffer as input. APInt has made unfortunate sign choices though, IIR...

Neil Booth wrote: > Talin wrote:- > >> On the other hand, writing an interpreter means duplicating a lot of >> the functionality that's already in LLVM. For example, consider just >> the problem of float to int conversions: >> >> char B[ (int)3.0 ]; >> >> Generating code for this is relatively simple; Converting >> arbitrary-sized

...ebraic simplification. If we have a math > operation that cannot wrap, then it notionally produces as many bits of > undef as the operation could possibly produce. For example, "add nsw i8" can > produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit > bitpattern. This is strong enough to do things like "a + 1 > a --> true", > because on overflow of "a + 1" we can choose an poison value of "MAX_INT + > 1", even though that is not a valid i8 bit pattern. > > So, a short version would be that poison is like un...

...I'm looking at the new ARM disassembler, and performing testing to see if there are any obvious bugs I can fix. Overall it looks really nice - I've only found one obvious bug that I'm packaging up a patch for now. Currently it does not provide information as to whether a particular bitpattern was UNPREDICTABLE or not. For example, an invalid bitpattern may return correct disassembly for an alternative, predictable instruction meaning that the sequence X -> disassemble -> assemble -> Y could end up with X being different to Y. This is fine, however there should be some notif...

Well in IEEE-754 Nan + any value returns Nan, so doing Nan + undef -> undef is wrong. I agree that undef are usually the results of a bad application behavior I'm just wondering what is the right thing to do. Thomas -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Wednesday, December 11, 2013 12:15 PM To: Raoux, Thomas F Cc: Philip Reames; llvmdev

On 11 December 2013 20:25, Raoux, Thomas F <thomas.f.raoux at intel.com> wrote: > Well in IEEE-754 Nan + any value returns Nan, so doing Nan + undef -> undef is wrong. I see what you mean having re-read the language reference. It looks like LLVM's "undef" has to be *some* bitpattern at any point, and that allows IEEE room to come in and say what the result is. Tim.

...simply supports algebraic simplification. If we have a math operation that cannot wrap, then it notionally produces as many bits of undef as the operation could possibly produce. For example, "add nsw i8" can produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit bitpattern. This is strong enough to do things like "a + 1 > a --> true", because on overflow of "a + 1" we can choose an poison value of "MAX_INT + 1", even though that is not a valid i8 bit pattern. So, a short version would be that poison is like undef, except you get...

...20:25, Raoux, Thomas F <thomas.f.raoux at intel.com> wrote: >> Well in IEEE-754 Nan + any value returns Nan, so doing Nan + undef -> undef is wrong. > > I see what you mean having re-read the language reference. It looks > like LLVM's "undef" has to be *some* bitpattern at any point, and that > allows IEEE room to come in and say what the result is. To generalize this, undef can be any bit pattern, but it still has to respect universal constraints of its type. This means that predicates that are true for all values of a type must also be true for undef. Beca...

Hello, I'm wondering how I can create an atomic load and add instruction for floating point values. If I use IRBuilder::CreateAtomicRMW() I get the error message: "atomicrmw operand must have integer type". I am using LLVM 3.4 and the only system I need to support is x86.

...xpected values; I'm assuming that what is returned is an APInt >> containing the bitwise representation of the floating-point value? >> > > Only two convert to integer. The convertToAPInt is unfortunately > named; I'm not sure what it does but suspect it captures bitpatterns > like you suggest. > > convertToInteger is the function I'm responsible for and it does > float->int conversion according to IEEE754. If you want to place > it in an APInt, create your APInt with the appropriate size and > use its buffer as input. APInt has made unfortu...

Hi Mihail, > static DecodeStatus CheckNEONConstraint(const MCInst &Inst, unsigned Insn) [...] > ConstraintCheckMethod = "CheckNEONConstraint" In general I like the idea of an instruction-validation method. I think it could also potentially solve the SoftFail/UNPREDICTABLE issues that are looming (and partially resolved for decoding at present). However, I think that to cope

...e a math >>> operation that cannot wrap, then it notionally produces as many bits of >>> undef as the operation could possibly produce. For example, "add nsw i8" can >>> produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit >>> bitpattern. This is strong enough to do things like "a + 1 > a --> true", >>> because on overflow of "a + 1" we can choose an poison value of "MAX_INT + >>> 1", even though that is not a valid i8 bit pattern. >>> >>> So, a short version...

...ation. If we have a math >> operation that cannot wrap, then it notionally produces as many bits of >> undef as the operation could possibly produce. For example, "add nsw i8" can >> produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit >> bitpattern. This is strong enough to do things like "a + 1 > a --> true", >> because on overflow of "a + 1" we can choose an poison value of "MAX_INT + >> 1", even though that is not a valid i8 bit pattern. >> >> So, a short version would be that...

...;>> operation that cannot wrap, then it notionally produces as many bits of >>>> undef as the operation could possibly produce. For example, "add nsw i8" can >>>> produce an i9 undef, and "mul nsw i8" can produce an undefined 16 bit >>>> bitpattern. This is strong enough to do things like "a + 1 > a --> true", >>>> because on overflow of "a + 1" we can choose an poison value of "MAX_INT + >>>> 1", even though that is not a valid i8 bit pattern. >>>> >>>> So...