search for: raoux

...t<Constant>(SI->getOperand(1))) if (C->isNullValue()) { LI.setOperand(0, SI->getOperand(2)); return &LI; } So it is a bug? -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Thursday, December 11, 2014 11:13 AM To: Raoux, Thomas F Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Dereferencing null pointers ----- Original Message ----- > From: "Thomas F Raoux" <thomas.f.raoux at intel.com> > To: llvmdev at cs.uiuc.edu > Sent: Thursday, December 11, 2014 1:03:39 PM > Subject: [LLVMdev] D...

...le type (i8/i16/ /// i32/i64/float/double) and must be a ConstantFP or ConstantInt. static Constant *getSplat(unsigned NumElts, Constant *Elt); Cheers, Thomas -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Thursday, January 15, 2015 6:36 AM To: Raoux, Thomas F; LLVM Developers Mailing List Subject: Re: [LLVMdev] Bug in InsertElement constant propagation? I'm not sure what the right fix is. I don't see a way to get the float out of APFloat without a copy happening. The usual trick to copy a float somewhere else but preserve the NaN bits...

...+ 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 at cs.uiuc.edu Subject: Re: [LLVMdev] Float undef value propagation On 11 December 2013 20:08, Raoux, Thomas F <thomas.f.raoux at intel.com> wrote: > You are right some cases would definitely not be right like undef + > Nan -> undef. For 2.0f ca...

...gh. Did I oversee that? Is the solution to had a new get function in ConstantDataVector to allow that? Any hint on what would be the right fix otherwise? Thomas -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 10:30 AM To: Raoux, Thomas F; LLVM Developers Mailing List Subject: Re: [LLVMdev] Bug in InsertElement constant propagation? On 1/14/15 11:12 AM, Raoux, Thomas F wrote: > Ha here is what I was missing. Thanks Jon. It still seems to me that the transformation of LLVM IR is invalid is that right? I don't know...

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "Thomas F Raoux" <thomas.f.raoux at intel.com>, llvmdev at cs.uiuc.edu > Sent: Tuesday, July 14, 2015 11:59:49 PM > Subject: Re: [LLVMdev] LICM for function calls > > On 07/14/2015 07:45 AM, Raoux, Thomas F wrote: > > Hi, > > > > Right now in LICM (and many other transform...

...iuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Philip Reames Sent: Tuesday, December 10, 2013 12:56 PM To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] Float undef value propagation On 12/9/13 2:13 PM, Raoux, Thomas F wrote: Constant propagation pass generates constant expression when undef is used in float instructions instead of propagating the undef value. ; Function Attrs: nounwind define float @_Z1fv() #0 { entry: %add = fadd fast float undef, 2.000000e+00 ret float %add } Becomes: ; Functi...

On 11 December 2013 20:08, Raoux, Thomas F <thomas.f.raoux at intel.com> wrote: > You are right some cases would definitely not be right like undef + Nan -> > undef. For 2.0f case I’m not sure either if any bits could be known. Do you have an example where that's unsafe? You usually have to do something pretty...

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 be *some* bitpattern at...

...seems to me that the transformation of LLVM IR is invalid is that right? I assume we shouldn't be converting APFloat to float in order to avoid such problems? -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 9:39 AM To: Raoux, Thomas F; LLVM Developers Mailing List Subject: Re: [LLVMdev] Bug in InsertElement constant propagation? On 1/14/15 9:22 AM, Raoux, Thomas F wrote: > Hi, > > When I run opt on the following LLVM IR: > > define i32 @foo() { > > bb0: > > %0 = bitcast i32 2139171423 t...

Hi, I would like to understand better the meaning of constant null pointer in LLVM IR. Can the optimizer assume that dereferencing a null pointer is always unreachable? Or is it only the case for address space 0? Is it ok to have null pointer be a valid pointer for an address space other than 0? In InstCombine pass in InstCombiner::visitLoadInst(LoadInst &LI) I see that we replace load of

Hi, Right now in LICM (and many other transformations) we always assume it is never safe to speculatively execute a function call. The following function always return false for all function calls except for few intrinsics: bool llvm::isSafeToSpeculativelyExecute(const Value *V, const DataLayout *TD) { ... case Instruction::Call: { if (const

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

...On Tuesday, July 14, 2015, Philip Reames <listmail at philipreames.com> wrote: > On 07/14/2015 10:25 PM, Hal Finkel wrote: > >> ----- Original Message ----- >> >>> From: "Philip Reames" <listmail at philipreames.com> >>> To: "Thomas F Raoux" <thomas.f.raoux at intel.com>, llvmdev at cs.uiuc.edu >>> Sent: Tuesday, July 14, 2015 11:59:49 PM >>> Subject: Re: [LLVMdev] LICM for function calls >>> >>> On 07/14/2015 07:45 AM, Raoux, Thomas F wrote: >>> >>>> Hi, >>>...

...nvariant function call into the pre-header of a loop where the trip count is unknown - and, in particular, not known to be > 0. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent: Thursday, July 16, 2015 08:38 To: Raoux, Thomas F Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LICM for function calls I think we'd need some kind of 'safe_to_speculate' attribute on the function. Regarding the optimization, under what circumstances would you want to speculate a function? I can imagine doing this only i...

On 12/11/13 12:40 PM, Owen Anderson wrote: > > On Dec 11, 2013, at 12:33 PM, Tim Northover <t.p.northover at gmail.com > <mailto:t.p.northover at gmail.com>> wrote: > >> On 11 December 2013 20:25, Raoux, Thomas F <thomas.f.raoux at intel.com >> <mailto: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....

...mes < listmail at philipreames.com >>> wrote: >> >> On 07/14/2015 10:25 PM, Hal Finkel wrote: >> >> >> ----- Original Message ----- >> >> >> From: "Philip Reames" < listmail at philipreames.com > >> To: "Thomas F Raoux" < thomas.f.raoux at intel.com >, >> llvmdev at cs.uiuc.edu >> Sent: Tuesday, July 14, 2015 11:59:49 PM >> Subject: Re: [LLVMdev] LICM for function calls >> >> On 07/14/2015 07:45 AM, Raoux, Thomas F wrote: >> >> >> Hi, >> >> Ri...

Constant propagation pass generates constant expression when undef is used in float instructions instead of propagating the undef value. ; Function Attrs: nounwind define float @_Z1fv() #0 { entry: %add = fadd fast float undef, 2.000000e+00 ret float %add } Becomes: ; Function Attrs: nounwind define float @_Z1fv() #0 { entry: ret float fadd (float undef, float 2.000000e+00) } Is it safe

Hi, When I run opt on the following LLVM IR: define i32 @foo() { bb0: %0 = bitcast i32 2139171423 to float %1 = insertelement <1 x float> undef, float %0, i32 0 %2 = extractelement <1 x float> %1, i32 0 %3 = bitcast float %2 to i32 ret i32 %3 } -> It generates: define i32 @foo() { bb0: ret i32 2143365727 } While tracking the value I see that the floating point value

On 12/9/13 2:13 PM, Raoux, Thomas F wrote: > > Constant propagation pass generates constant expression when undef is > used in float instructions instead of propagating the undef value. > > ; Function Attrs: nounwind > > define float @_Z1fv() #0 { > > entry: > > %add = fadd fast float und...

Ping? (Is there a code owner for AA, btw?) From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kuperstein, Michael M Sent: Tuesday, May 21, 2013 18:23 To: LLVMdev at cs.uiuc.edu Cc: Raoux, Thomas F Subject: [LLVMdev] Mixing noalias and regular arguments Hi all, I'm trying to understand the semantics of noalias arguments, and I'm not entirely sure I got it correctly. To the best of my understanding, if an argument is declared noalias, "This indicates that pointer value...