search for: sqrtpd

...e that I've been getting, both with > CodeGenOpt::Default and CodeGenOpt::None . The crash isn't occurring with > CodeGenOpt::None, but that seems to be because ECX isn't being used - it > still gets set to 0x7fffffff by one of the calls to 76719BA1 > > I notice that X86::SQRTPD[m|r] appear in X86InstrInfo::isHighLatencyDef. I > was thinking an optimization might be removing it, but I don't get the > sqrtpd instruction even if the createJIT optimization level turned off. > > I am trying this with the Release 3.3 code - I'll try it with trunk and > se...

...[(X86WinFTOL RFP64:$src)]>, Requires<[In32BitMode]>; } On Thu, Jul 18, 2013 at 11:59 PM, Peter Newman <peter at uformia.com> wrote: > Oh, excellent point, I agree. My bad. Now that I'm not assuming those > are the sqrt, I see the sqrtpd's in the output. Also there are three > fptoui's and there are 3 call instances. > > (Changing subject line again.) > > Now it looks like it's bug #13862 > > On 19/07/2013 4:51 PM, Craig Topper wrote: > > I think those calls correspond to this > > %11...

...FP64:$src)]>, > Requires<[In32BitMode]>; > } > > > On Thu, Jul 18, 2013 at 11:59 PM, Peter Newman <peter at uformia.com> wrote: > >> Oh, excellent point, I agree. My bad. Now that I'm not assuming those >> are the sqrt, I see the sqrtpd's in the output. Also there are three >> fptoui's and there are 3 call instances. >> >> (Changing subject line again.) >> >> Now it looks like it's bug #13862 >> >> On 19/07/2013 4:51 PM, Craig Topper wrote: >> >> I think those calls...

Oh, excellent point, I agree. My bad. Now that I'm not assuming those are the sqrt, I see the sqrtpd's in the output. Also there are three fptoui's and there are 3 call instances. (Changing subject line again.) Now it looks like it's bug #13862 On 19/07/2013 4:51 PM, Craig Topper wrote: > I think those calls correspond to this > > %110 = fptoui double %109 to i32 > &g...

...Requires<[In32BitMode]>; >> } >> >> >> On Thu, Jul 18, 2013 at 11:59 PM, Peter Newman <peter at uformia.com> wrote: >> >>> Oh, excellent point, I agree. My bad. Now that I'm not assuming those >>> are the sqrt, I see the sqrtpd's in the output. Also there are three >>> fptoui's and there are 3 call instances. >>> >>> (Changing subject line again.) >>> >>> Now it looks like it's bug #13862 >>> >>> On 19/07/2013 4:51 PM, Craig Topper wrote: >>&...

...Requires<[In32BitMode]>; > } > > > On Thu, Jul 18, 2013 at 11:59 PM, Peter Newman <peter at uformia.com > <mailto:peter at uformia.com>> wrote: > > Oh, excellent point, I agree. My bad. Now that I'm not assuming > those are the sqrt, I see the sqrtpd's in the output. Also there > are three fptoui's and there are 3 call instances. > > (Changing subject line again.) > > Now it looks like it's bug #13862 > > On 19/07/2013 4:51 PM, Craig Topper wrote: >> I think those calls correspond to th...

...> >> >> On Thu, Jul 18, 2013 at 11:59 PM, Peter Newman <peter at uformia.com >> <mailto:peter at uformia.com>> wrote: >> >> Oh, excellent point, I agree. My bad. Now that I'm not >> assuming those are the sqrt, I see the sqrtpd's in the >> output. Also there are three fptoui's and there are 3 call >> instances. >> >> (Changing subject line again.) >> >> Now it looks like it's bug #13862 >> >> On 19/07/2013 4:51 PM, Craig To...

...n Thu, Jul 18, 2013 at 11:59 PM, Peter Newman >>> <peter at uformia.com <mailto:peter at uformia.com>> wrote: >>> >>> Oh, excellent point, I agree. My bad. Now that I'm not >>> assuming those are the sqrt, I see the sqrtpd's in the >>> output. Also there are three fptoui's and there are 3 >>> call instances. >>> >>> (Changing subject line again.) >>> >>> Now it looks like it's bug #13862 >>> >...

Hmm, I'm not able to get those .ll files to compile if I disable SSE and I end up with SSE instructions(including sqrtpd) if I don't disable it. On Thu, Jul 18, 2013 at 10:53 PM, Peter Newman <peter at uformia.com> wrote: > Is there something specifically required to enable SSE? If it's not > detected as available (based from the target triple?) then I don't think we > enable it specifi...

...hing the compiled code that I've been getting, both with CodeGenOpt::Default and CodeGenOpt::None . The crash isn't occurring with CodeGenOpt::None, but that seems to be because ECX isn't being used - it still gets set to 0x7fffffff by one of the calls to 76719BA1 I notice that X86::SQRTPD[m|r] appear in X86InstrInfo::isHighLatencyDef. I was thinking an optimization might be removing it, but I don't get the sqrtpd instruction even if the createJIT optimization level turned off. I am trying this with the Release 3.3 code - I'll try it with trunk and see if I get a differen...

...; 76719BD8 add ecx,7FFFFFFFh > 76719BDE sbb eax,0 > 76719BE1 mov edx,dword ptr [esp+14h] > 76719BE5 sbb edx,0 > 76719BE8 leave > 76719BE9 ret > > > As you can see at 76719BD5, it modifies ECX . > > I don't know that this is the sqrtpd function (for example, I'm not seeing > any SSE instructions here?) but whatever it is, it's being called from the > IR I attached earlier, and is modifying ECX under some circumstances. > > > On 19/07/2013 3:29 PM, Craig Topper wrote: > > That should map directly to sq...

...7FFFFFFFh > 76719BDE sbb eax,0 > 76719BE1 mov edx,dword ptr [esp+14h] > 76719BE5 sbb edx,0 > 76719BE8 leave > 76719BE9 ret > > > As you can see at 76719BD5, it modifies ECX . > > I don't know that this is the sqrtpd function (for example, I'm > not seeing any SSE instructions here?) but whatever it is, it's > being called from the IR I attached earlier, and is modifying ECX > under some circumstances. > > > On 19/07/2013 3:29 PM, Craig Topper wrote: >> That s...

...[esp] 76719BD5 mov ecx,dword ptr [esp] 76719BD8 add ecx,7FFFFFFFh 76719BDE sbb eax,0 76719BE1 mov edx,dword ptr [esp+14h] 76719BE5 sbb edx,0 76719BE8 leave 76719BE9 ret As you can see at 76719BD5, it modifies ECX . I don't know that this is the sqrtpd function (for example, I'm not seeing any SSE instructions here?) but whatever it is, it's being called from the IR I attached earlier, and is modifying ECX under some circumstances. On 19/07/2013 3:29 PM, Craig Topper wrote: > That should map directly to sqrtpd which can't modif...

That should map directly to sqrtpd which can't modify ecx. On Thu, Jul 18, 2013 at 10:27 PM, Peter Newman <peter at uformia.com> wrote: > Sorry, that should have been llvm.x86.sse2.sqrt.pd > > > On 19/07/2013 3:25 PM, Craig Topper wrote: > > What is "frep.x86.sse2.sqrt.pd". I'm only fami...

Sorry, that should have been llvm.x86.sse2.sqrt.pd On 19/07/2013 3:25 PM, Craig Topper wrote: > What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things > prefixed with "llvm.x86". > > > On Thu, Jul 18, 2013 at 10:12 PM, Peter Newman <peter at uformia.com > <mailto:peter at uformia.com>> wrote: > > After stepping through the

What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things prefixed with "llvm.x86". On Thu, Jul 18, 2013 at 10:12 PM, Peter Newman <peter at uformia.com> wrote: > After stepping through the produced assembly, I believe I have a culprit. > > One of the calls to @frep.x86.sse2.sqrt.pd is modifying the value of ECX - > while the produced code is