search for: sse1

There is some redundancy at the instruction format level in the x86 .td files. For example, in X86InstrFormats.td: // SSE1 Instruction Templates: // // SSI - SSE1 instructions with XS prefix. class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> pattern> : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>; // SSE3 Instruction Templates: // S3SI -...

On Monday 30 March 2009 16:12, David Greene wrote: > There is some redundancy at the instruction format level in the x86 .td > files. For example, in X86InstrFormats.td: > > // SSE1 Instruction Templates: > // > // SSI - SSE1 instructions with XS prefix. > > class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> > pattern> > > : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>; > > //...

...tures as function attribute : "target-features"="+mmx" In the SelectionDAG phase in file "X86ISelLowering.cpp", i checked in one of the function what is the subtarget feature by calling few routines of Subtarget. Subtarget->hasMMX() ------ true Subtarget->hasSSE1() ------ true Subtarget->hasSSE2() ------ true These functions just compare the X86SSELevel with subtarget enum values like MMX, SSE1, SSE2 etc. hasMMX() { return X86SSELevel >= MMX}; // similar for others Now, enum values start from MMX and goes on increasing with SSE1, SSE2, etc. For t...

...e code if(info->ia32.fxsr || info->ia32.sse || info->ia32.sse2) { [...] } was replaced by if(info->ia32.sse) { [...] } else info->ia32.fxsr = info->ia32.sse = [...] = false; Reason: there's no point to test OS SSE support if SSE (SSE1) is not supported by CPU. Also the detection code tries to execute SSE1 instruction xorps; it doesn't make sense if SSE1 isn't supported (i.e. info->ia32.sse==false). If info->ia32.sse is true then both old and new conditions are true. The 'else' branch isn't necessary but...

...te interrupts which will > lead to a SIGFPE signal which terminates the program (unless caught by a > SIGFPE handler). > """ I don't see what this has to do with anything, but... > Is there a way I can disable SSE instruction generation in LLVM ? Yes. Pass -mattr=-sse1,-sse2,-sse3 to lli or llc. If you've linked the JIT into your app, you can specify this by calling cl::ParseCommandLineOptions on an static array, something like: int argc; char *Args[] = { "", "-mattr=-sse1,-sse2,-sse3", 0 }; cl::ParseCommandLineOptions(argc, Args, 0);...

...e second source object class (register or memory, depending) // DSTCLASS - The destination object class (register or memory, depending) // ADDRCLASS - Either 'addr' or REGCLASS, depending // MEMOP - Either 'memop' or 'srcvalue,' depending // Scalar defm FsANDN : sse1_sse2_avx_binary_scalar_xs_xd_node_pattern_rm_rrm< 0x55, "andn", [[(set DSTREGCLASS:$dst, (INTTYPE (and (not (INTTYPE (bitconvert (TYPE SRCREGCLASS:$src1)))), (I...

...e created. > for (ii in c(1:4)){ + SSE[ii]=rbind(anova(fit[ii])$"Sum Sq") + dfe[ii]=rbind(summary(fit[ii])$df) + } Error in anova(fit[ii]) : object 'fit' not found Why isn't it looking for object 'fit1' instead of 'fit'? The idea is that it would store in SSE1 the Sum Sq of the model fit1, and so on for the other 3 models. Is there a way to do this in R? I can do it in Stata, but am only somewhat knowledgeable in R. -Michael [[alternative HTML version deleted]]

...have the same problem within the GPR operations. Ideally we'd have a multiclass for most arithmetic operations that expands out into 8/16/32/64-bit operations, perhaps even handling reg/reg, reg/ imm, and reg/mem versions all at the same time. Similar things should probably be done for SSE1/2 since it adds double versions of all the float operations that SSE1 has. > For AVX we would need a different set of format classes because > while AVX > could reuse the existing XS class (it's recoded as part of the VEX > prefix so > we still need the information XS prov...

...bit/stereo; best compression mode (flac -8); CPU = Core i7. Here are the results (1st column: SSE instruction set, 2nd column: the state of precompute_partition_info_sums_32bit_asm_ia32_(), 3rd column: encoding time in seconds, smaller=better): no SSE disabled 53.9 no SSE enabled 55.2 SSE1 disabled 53.9 SSE1 enabled 55.3 SSE2 disabled 51.9 SSE2 enabled 53.1 SSE3 disabled 51.8 SSE3 enabled 53.2 SSSE3 disabled 45.7 SSSE3 enabled 51.4 SSE41 disabled 46.1 SSE41 enabled 51.6 SSE42 disabled 46.1 SSE42 ena...

On Wed, 19 Apr 2006 19:28:34 +0100 Simon Burton <simon at arrowtheory.com> wrote: > > >From what I remember, this is a bug in debian libc: > some floating point flags are set incorrectly causing SIGFPE. > Can't find the bug report ATM. Oh, it just showed up on numpy-discussion: http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 """ #include

> We agree on not supporting the non-FP version, however the run time flags > need to be settable with a non FP SSE mode so that exceptions are avoided. I think we should keep the more "official" naming and not AMD's, which is more confusing. SSE means SSE1: all the SSE instructions (including the ones using xmm registers). What AMD calls SSE is not SSE at all. Basically, it's a bunch of "extra instructions" borrowed from SSE and that are part of the extended 3DNow!. > I thus propose a set of defines like this instead of the ones in...

On Tue, 18 Apr 2006 23:27:39 -0700 Evan Cheng <evan.cheng at apple.com> wrote: > Hi Simon, > > The x86 backend does generate scalar SSE2 instructions. For your > example, it should emit something like: Oh, how did you get this ? [...] > > There is nothing here that should cause an exception. Are you using a > release or cvs? CVS. >From what I remember,

On Mar 30, 2009, at 2:53 PM, David Greene wrote: > On Monday 30 March 2009 16:12, David Greene wrote: >> There is some redundancy at the instruction format level in the >> x86 .td >> files. For example, in X86InstrFormats.td: >> >> // SSE1 Instruction Templates: >> // >> // SSI - SSE1 instructions with XS prefix. >> >> class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, >> list<dag> >> pattern> >> >> : I<o, F, outs, ins, asm, pattern>, XS, Re...

...testing the release!! I've checked out the nightly test report and it looks like there is potentially one regression. SingleSource/UnitTests/Vector/SSE/sse.expandfft However, I need you to look at your /proc/cpuinfo (or whatever it is on FreeBSD) to tell me what flavors of sse you have (mmx, sse1, sse2, etc). Thanks, Tanya > > --Emil > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >

I've been working on adding AVX to LLVM and have run across a number of questions. Here's the first one. In some ways AVX is "just another" SSE level. Having AVX implies you have SSE1-SSE4.2. However AVX is very different from SSE and there are a number of sub-features which may or may not be available on various implementations. So right now I've done this: def FeatureYMM : SubtargetFeature<"ymm", "X86YMM", "true", // Cray...

...m 4 detects it just fine. OK, I have gone though the doc and I think I understand. What they call plain "SSE" (no FP) is actually the (very) incomplete SSE implementation they had in the Classic and T-Bird Athlon. What they call SSEFP is actually what Intel calls "SSE" or "SSE1". Only the Athlon XP (and newer) CPU implements all of SSE1. Now about supporting what you call the "non FP version" (AMD's incomplete implementation), I say it's not worth it. There's no gain because all this provides is prefetch functions which are going to be useless...

I am about to get a new machine at work - an IBM Intellistation with the Xeon 2.8 GB processor. It will run Windows 2000. I would like to install the proper ATLAS dll for this machine, but I am not sure if Xeon is P4? Does anybody have any experience with Xeon? Thanks in advance, Andy __________________________________ Andy Jaworski 518-1-01 Process Laboratory 3M Corporate Research Laboratory

...ctions: using finite difference derivatives, it is straightforward. You define a new residual function, resid2, that evaluates both old residual functions, and returns their scaled sums. So if you had foo1(par1, ...) and foo2(par2, ...) you define resid2 <- function(c(par1,par2), ...) { sse1 <- foo1(par1, ...) sse2 <- foo2(par2, ...) return(sse1 * w1 + sse2 * w2) } w1 and w2 are weights that determine how much each of the old residual functions contributes to the combined fit. Hope this helps, and best regards, Kate -- Katharine Mullen Structure Determination Methods G...

Hi, I have an ir at the end of this email. Run it with: llc -mcpu=i386 -march=x86-64 -mattr=-sse2 and get assertion below. Changing cpu does not help. I am using llc from the latest svn repository. Any suggestions to work around this? I need to disable sse2 instructions for x86-64. Thanks, -Peng -----error message------ llc: X86FloatingPoint.cpp:332: unsigned int getFPReg(const

...little experiment to see if I can unify all > > SSE and AVX > > SIMD instructions under one framework. I'll leave MMX and 3dNow > > alone since > > they're oddballs and hardly anyone uses them. > > Ok. I agree that the similarity being factored here is across SSE1/2/ > AVX. And SSE3/4. > > I have a Perl script that auto-generates the necessary mutliclass > > combinations > > as well as the needed base classes depending on what's in the top- > > level .td > > file. For now, I've named that top-level file X86InstrSI...