search for: bitpatterns

Hello all, I would like to assign some bits in the instructions, based on the order of mnemonics that appear 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:

...nstructions that can only be executed unconditionally. Notably, this includes most of the VFP instructions. [2] Other types of failure can be detected by MC Hammer. These results can be published if there is interest in seeing them. [3] LLVM built with assertions turned on hits SIGABRT on some bitpatterns. When this occurs the rest of the slice is not run, so to cover the whole slice we are using an version of LLVM with no assertions. One would expect an assertion to catch early a genuine codegen failure so hopefully bugs that would have triggered an assertion will still show up without them on. [4...

...test space then I will consider requests. Regards, Richard Barton ARM Ltd, Cambridge ==================== [1] Other types of failure can be detected by MC Hammer. These results can be published if there is interest in seeing them. [2] LLVM built with assertions turned on hits SIGABRT on some bitpatterns. When this occurs the rest of the slice is not run, so to cover the whole slice we are using an version of LLVM with no assertions. One would expect an assertion to catch early a genuine codegen failure so hopefully bugs that would have triggered an assertion will still show up without them on. [3...

On Aug 11, 2011, at 1:32 AM, James Molloy wrote: > Hi, > > 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. Glad you're liking it! I haven't really done comprehensive testing yet—it passes all the decoding tests

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

On 22 January 2016 at 12:20, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> 1) I realise this is a somewhat silly question, but is this still >> acceptable "undefined 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

...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, IIRC...

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

> I've been discussing a model with David that might steer poison back towards > something that 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

Hi, 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

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.

On Wed, Jan 28, 2015 at 8:53 PM, Philip Reames <listmail at philipreames.com> wrote: > On 01/28/2015 07:02 AM, Sean Silva wrote: > > Could you maybe provide an example where replacing `%always_poison` with > `undef` will change the meaning? At least for me, the thing that I'm most > unclear about is how poison differs from undef. > > I will second this request for

On Dec 11, 2013, at 12:33 PM, Tim Northover <t.p.northover at gmail.com> wrote: > 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

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 unfortun...

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

One way around this is to say that there are some special instructions, icmp, sext and zext which produce a value solely composed of poison bits if any of their input bits is poison. So `<poison> icmp X` is poison for any value of X, including INT_MAX. This is one way poison could be fundamentally different from undef. -- Sanjoy On Thu, Jan 29, 2015 at 8:05 PM, Matthias Braun <matze at

Having though about this some more I think optimizing (x+1 > x) <=> true and at the same time modeling undefined behavior as a posion value is impossible. This is because we also want the following rule: (x > INT_MAX) <=> false Now if poison is a value, then the second replacement tells us (poison > INT_MAX) == false which contradicts the first rule. The only way out of

But (Poison > INT_MAX) <=> poison contradicts (X > INT_MAX) <=> false and I don't think you want to abandon the second rule just because x might be poison. - Matthias > On Jan 29, 2015, at 9:43 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > One way around this is to say that there are some special > instructions, icmp, sext and zext which