similar to: undef * 0

Displaying 20 results from an estimated 10000 matches similar to: "undef * 0"

2016 Sep 02
3
undef * 0
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
2016 Sep 14
2
undef * 0
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
2016 Sep 13
2
undef * 0
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
2012 Nov 15
2
[LLVMdev] X86 rsqrt instruction generated
Hi, We have implemented the rsqrt instruction generation for X86 target architecture. We have introduced a flag -fp-rsqrt flag which controls the generatation of X86 rsqrt instruction generation. We have observed minor effects on precision due to rsqrt and hence has put these transformations under the mentioned flag. Note that -fp-rsqrt is only enabled with -enable-unsafe-fp-math flag presently.
2012 Nov 15
0
[LLVMdev] X86 rsqrt instruction generated
On Wed, Nov 14, 2012 at 10:43 PM, Chakraborty, Soham <Soham.Chakraborty at amd.com> wrote: > Hi, > > > > We have implemented the rsqrt instruction generation for X86 target > architecture. We have introduced a flag -fp-rsqrt flag which controls the > generatation of X86 rsqrt instruction generation. > > We have observed minor effects on precision due to rsqrt and
2016 Sep 13
3
undef * 0
Hi Soham, You're right that in LLVM IR arithmetic (with the current definition of `undef`) is not distributive. You can't replace `A * (B + C)` with `A * B + A * C` in general, since (exactly as you said) for A = `undef`, B = `1`, C = `-1` the former always computes `0` while the latter computes `undef`. This is fundamentally because replacing `A * (B + C)` with `A * B + A * C`
2012 Nov 27
2
order.max specification problem in the ar.ols function
Hello I am facing a curious problem.I have a time series data with which i want to fit auto-regressive model of order p, where p runs from 1:9.I am using a for loop which will fit an AR(p) model for each value of p using the *ar.ols* function. I am using the following code for ( p in 1:9){ a=ar.ols (x=data.ts, order.max=p, demean=T, intercept=T) } Specifying the *order.max* to be p, it gives me a
2012 Dec 03
1
[LLVMdev] X86 rsqrt instruction generated
Hi, Please find attached the modified patch and description. We have modified and retested the patch taking into consideration the comments and inputs provided earlier. Thanks & Regards, soham -----Original Message----- From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Thursday, November 15, 2012 12:59 PM To: Chakraborty, Soham Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev]
2012 Nov 05
1
[LLVMdev] adding architecture specific flag
Hi, Can anybody please suggest where to add architecture specific code generation flags(e.g. X86) in llvm? Thanks in advance. Best Regards, soham
2015 Jan 26
3
[LLVMdev] LLVM introduces racy read - Unsafe transformation?
Hi, I agree that the earlier example was already racy due to shared flag variable. Sorry for the wrong example. Please ignore it. I have modified the program as follows. The only shared variable is 'a' and the following is a non-racy program. int a; int readA(bool flag) { int r=0; if(flag) { r = a; } return r; } void writeA(){ a = 42; } int main() { bool flag = false;
2018 Jun 26
2
How to force an unused function declaration in clang
It does, when the function has a body. When it doesn't, it ignores <https://godbolt.org/g/2BCvht>. The body might be provided later on in the toolchain via linking a library. Regards, Soham Sinha PhD Student, Department of Computer Science Boston University On Tue, Jun 26, 2018 at 10:25 AM Hans Wennborg <hans at chromium.org> wrote: > It works for me: > >
2010 Jul 06
2
[LLVMdev] ConstantFold 'undef xor undef'
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)
2018 Jun 26
2
How to force an unused function declaration in clang
For the same reason GCC allowed the attribute. Even if I want to use/inline a function later on in the pipeline. Regards, Soham Sinha PhD Student, Department of Computer Science Boston University On Tue, Jun 26, 2018 at 8:30 AM mayuyu.io <admin at mayuyu.io> wrote: > Out of curiosity, how does an unused declaration affect the emitted object > file > > Zhang > > > 在
2010 Jul 07
0
[LLVMdev] ConstantFold 'undef xor undef'
On Jul 6, 2010, at 3:37 PM, Jianzhou Zhao wrote: > Which semantics is better? I guess both are fine because if we assume > these two def's are same, then it is 0 as > 'ConstantFoldBinaryInstruction', while if we assume they are different > then it is equal to undef. But the second case seems to include the > first one. If we let undef xor undef to be undef, later we can
2014 Aug 27
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
> On Aug 27, 2014, at 6:34 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: > > I think you should try to get LLVM floating point experts involved, to find out their opinion about whether LLVM should really assume that snans always trap. > > If they think it is fine to assume trapping, then you can fold any floating point operation with an "undef" operand
2010 Jul 07
2
[LLVMdev] ConstantFold 'undef xor undef'
On Tue, Jul 6, 2010 at 8:34 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 6, 2010, at 3:37 PM, Jianzhou Zhao wrote: > >> Which semantics is better? I guess both are fine because if we assume >> these two def's are same, then it is 0 as >> 'ConstantFoldBinaryInstruction', while if we assume they are different >> then it is equal to
2014 Aug 28
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
On Aug 28, 2014, at 3:03 AM, Duncan Sands <duncan.sands at deepbluecap.com> wrote: > Hi Owen, > > On 27/08/14 19:06, Owen Anderson wrote: >> >>> On Aug 27, 2014, at 6:34 AM, Duncan Sands <duncan.sands at deepbluecap.com >>> <mailto:duncan.sands at deepbluecap.com>> wrote: >>> >>> I think you should try to get LLVM floating
2014 Aug 26
2
[LLVMdev] Bug 16257 - fmul of undef ConstantExpr not folded to undef
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
2013 Dec 13
2
[LLVMdev] Float undef value propagation
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,
2013 Dec 15
0
[LLVMdev] Float undef value propagation
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