search for: undefs

Hi, > Both A and B are undef: > LHS = (undef & undef) | (undef & undef) = undef // Since ~undef = undef > RHS = undef > Thus transform is correct. LLVM documentation (http://llvm.org/docs/LangRef.html#undefined-values) suggests that it is unsafe to consider (a & undef = undef) and (a | undef = undef). "As such, it is unsafe to optimize or assume

Details of installation attached. Effect: when I build and test (with full path names) ssh in the openssh... directory, everything works fine. When I "install" it as per attached file into a test-directory and run it from there, there are 2 phenomena: either it just hangs, eating 96% of CPU or it dies with a Segmentation fault (this is what happens most often) Help needed

Thanks for your answers. Another example of unsound transformation on Boolean algebra. According to the LLVM documentation (http://llvm.org/docs/LangRef.html#undefined-values) it is unsafe to consider ' a & undef = undef ' and ' a | undef = undef ' but 'undef xor undef = undef' is safe. Now, given an expression ((a & (~b)) | ((~a) & b)) where a and b are

Hi Duncan, Thank you for your comment to the bug 16257. I am new to LLVM, so not all the aspects of LLVM's /"undef"/ seem clear to me yet. I read and understood the examples from the LLVM documentation: http://llvm.org/docs/LangRef.html#undefined-values However, those examples do not cover all of the possible contexts where /"undef"/ can appear. E.g., I can't

...d > "mul 0, undef" to undef since no matter what value you substitute for > "undef" the output of the mul will always be zero. Note that in > something like "mul undef, undef", where undef occurs more than once, > you are allowed to assume that the two undefs are independent of each > other, uncorrelated, i.e. in your reasoning you can insert any bit > pattern for the first undef and any other bit pattern for the second > undef. > > Here is a proof that "mul undef, undef" is undef. Let R represent an > arbitrary bit patt...

...matter what value you substitute for "undef" the output of >>> the mul >>> will always be zero. Note that in something like "mul undef, >>> undef", where >>> undef occurs more than once, you are allowed to assume that the two >>> undefs are >>> independent of each other, uncorrelated, i.e. in your reasoning you >>> can insert >>> any bit pattern for the first undef and any other bit pattern for >>> the second >>> undef. >>> >>> Here is a proof that "mul undef, u...

On 12/14/2013 05:18 PM, Dan Gohman wrote: > On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com > <mailto:resistor at mac.com>> wrote: > > > On Dec 12, 2013, at 4:57 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > >> undef + any == NaN (since undef can be NaN) or undef +

I don't know of a way to do it from the command-line, but if you're willing to change the IR, you can add the optsize (for -Os) or minsize (for -Oz) IR attribute to the function you're compiling. On Fri, Sep 2, 2016 at 5:59 AM, Bruce Hoult via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Idle question, if anyone is reading still ... how do you get llc to do -Os > or

Hi, This is a follow up on a discussion around shufflevector with undef mask in https://reviews.llvm.org/D70641 and https://bugs.llvm.org/show_bug.cgi?id=43958. The current semantics of shufflevector in http://llvm.org/docs/LangRef.html#shufflevector-instruction states: "If the shuffle mask is undef, the result vector is undef. If any element of the mask operand is undef, that element

On Dec 12, 2013, at 4:57 PM, Philip Reames <listmail at philipreames.com> wrote: > undef + any == NaN (since undef can be NaN) or undef + any (since undef could be zero) undef + non-NaN is still undef. The compiler is free to choose any value of the type it wishes when simplifying an undef expression. The important point is that it still has to be a value of that type. Hence,

Hi Duncan, On 17.09.2014 21:10, Duncan Sands wrote: > Hi Oleg, > > On 17/09/14 18:45, Oleg Ranevskyy wrote: >> Hi, >> >> Thank you for all your helpful comments. >> >> To sum up, below is the list of correct folding examples for fadd: >> (1) fadd %x, -0.0 -> %x >> (2) fadd undef, undef -> undef

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -

Hi, At line 2292, lib/VMCore/ConstantFold.cpp (llvm2.7 release) Constant *llvm::ConstantFoldBinaryInstruction(unsigned Opcode, Constant *C1, Constant *C2) { ... // Handle UndefValue up front. if (isa<UndefValue>(C1) || isa<UndefValue>(C2)) { switch (Opcode) { case Instruction::Xor: if (isa<UndefValue>(C1)

Hi, ./configure --build x86_64-unknown-linux-gnu --host arm-linux-gnueabihf --disable-assertions --disable-check-asm --enable-intrinsics CFLAGS=-O3 --disable-shared When configuring with floating-point and intrinsics enabled as above, the generated config.h only has OPUS_ARM_MAY_HAVE_NEON_INTR defined (to 1), with /* #undef OPUS_ARM_ASM */ /* #undef OPUS_ARM_INLINE_ASM */ /* #undef

On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com> wrote: > > On Dec 12, 2013, at 4:57 PM, Philip Reames <listmail at philipreames.com> > wrote: > > undef + any == NaN (since undef can be NaN) or undef + any (since undef > could be zero) > > > undef + non-NaN is still undef. The compiler is free to choose any value > of the type it

Hello, I'd like to offer an alternative solution to the "poison problem": remove it. What follows is rather informal. I'd happily write up a nicer document if this RFC stands up to scrutiny. The idea was born from two observations: - undef was introduced to model a load of uninitialized memory, a form of undefined behavior. - poison was introduced to model integer overflow,

On Sun, Dec 15, 2013 at 5:12 PM, Philip Reames <listmail at philipreames.com>wrote: > On 12/14/2013 05:18 PM, Dan Gohman wrote: > >> On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com >> <mailto:resistor at mac.com>> wrote: >> >> >> On Dec 12, 2013, at 4:57 PM, Philip Reames >> <listmail at philipreames.com

Hi, Thank you for all your helpful comments. To sum up, below is the list of correct folding examples for fadd: (1) fadd %x, -0.0 -> %x (2) fadd undef, undef -> undef (3) fadd %x, undef -> NaN (undef is a NaN which is propagated) Looking through the code I found the "NoNaNs" flag accessed through an instance of

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de novembro de 2019 01:10 To: Nuno Lopes &...

...ative load? Is it to ensure that the subsequent uses of the value of the speculatively introduced load is caught/detected by the optimization? Is it possible to separate the "undef" in a sequential setting and "undef" with speculative loads in a concurrent setting with separate undefs? Thanks, Santosh -- Santosh G Nagarakatte, PhD Student, Computer and Information Science Department University of Pennsylvania, Philadelphia-19104 http://www.cis.upenn.edu/~santoshn