similar to: [LLVMdev] RFC: X86InstrFormats.td Refactoring

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

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

On Tuesday 31 March 2009 13:53, Dan Gohman wrote: > > class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, > > list<dag> pattern> > > > > : SSIb<o, F, outs, ins, asm, pattern>, Requires<HasSSE1>; > > Is this just factoring out the ", XS" part? As presented, it looks like > this change would introduce more

Hi all, I have a sample test case : $ cat 1.c int foo(int x, int y){ int z = x + y; return z/2; } I tried to get its IR form with clang providing subtarget feature as mmx for target x86_64 $ clang -O3 -mmmx 1.c -S -emit-llvm in the IR generated i can see the subtarget-features as function attribute : "target-features"="+mmx" In the SelectionDAG phase in file

Here's the big RFC. A I've gone through and designed patterns for AVX, I quickly realized that the existing SSE pattern specification, while functional, is less than ideal in terms of maintenance. In particular, a number of nearly-identical patterns are specified all over for nearly-identical instructions. For example: let Constraints = "$src1 = $dst" in { multiclass

On Mar 23, 2009, at 12:57 PM, David A. Greene wrote: > I'm looking at the instruction formats and I can't grok the > comments. For > example: > > // SSSE3 Instruction Templates: > // > // SS38I - SSSE3 instructions with T8 prefix. > // SS3AI - SSSE3 instructions with TA prefix. > // > > Where are these prefix names coming from? I can't find any

I'm looking at the instruction formats and I can't grok the comments. For example: // SSSE3 Instruction Templates: // // SS38I - SSSE3 instructions with T8 prefix. // SS3AI - SSSE3 instructions with TA prefix. // Where are these prefix names coming from? I can't find any mention of them in the Intel literature. Also, there's this curious table: // Prefix byte classes

On Apr 30, 2009, at 3:59 PM, David Greene wrote: > Here's the big RFC. > > A I've gone through and designed patterns for AVX, I quickly > realized that the > existing SSE pattern specification, while functional, is less than > ideal in > terms of maintenance. In particular, a number of nearly-identical > patterns > are specified all over for

On Thu, 20 Apr 2006, Simon Burton 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 <fenv.h> > void

Ok, so I've been chugging away at AVX and added some new features in TableGen to facilitate writing generic patterns. Here's an example: //===----------------------------------------------------------------------===// // Dummy defs for writing generic patterns //===----------------------------------------------------------------------===// def SRCREGCLASS; def DSTREGCLASS; def MEMCLASS;

OK for the DC. I noticed that converting users and groups to sid with the example below seems to work fine: # wbinfo -n DOMAIN\\user S-1-5-21-948789634-15155995-928725530-6864 SID_USER (1) # wbinfo -n DOMAIN\\group S-1-5-21-948789634-15155995-928725530-11178 SID_DOM_GROUP (2) However, applications using PAM and winbind seem to fail when trying to convert to sid. For instance, just to name one,

Hi Bruno, > Some comments: > > + // Try to synthesize horizontal adds from adds of shuffles. > + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) || > + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&& > + isHorizontalBinOp(LHS, RHS, true)) > > 1) You probably want to do something like: >

This patch synthesizes haddps/haddpd/hsubps/hsubpd instructions from floating point additions and subtractions of appropriate vector shuffles. To do this I introduced new x86 FHADD and FHSUB opcodes. These need to be wired up somehow in the .td file to the appropriate instructions. Since I have no idea how tablegen works I just hacked it in horribly. It works, but breaks support for the hadd

Folks, I am trying to get a loop to run which increments the object name as part of the loop. Here "fit1" "fit2" "fit3" and "fit4" are linear regression models that I have 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

Hi Duncan, On Wed, Sep 21, 2011 at 1:24 PM, Duncan Sands <baldrick at free.fr> wrote: > This patch synthesizes haddps/haddpd/hsubps/hsubpd instructions from > floating > point additions and subtractions of appropriate vector shuffles.  To do this > I > introduced new x86 FHADD and FHSUB opcodes.  These need to be wired up > somehow > in the .td file to the appropriate

Hi all, I think I found a bug in LLVM 3.0: When compiling for a target without SSE2 support, there were some 128-bit PXOR instructions in the generated code. I traced it down to the following definition in X86InstrSSE.td: def FsFLD0SS : I<0xEF, MRMInitReg, (outs FR32:$dst), (ins), "", [(set FR32:$dst, fp32imm0)]>,

Thanks Kevin for the reply. I got the point now :) On 10 Apr 2015 00:18, "Smith, Kevin B" <kevin.b.smith at intel.com> wrote: > For x86_64 ABI, a minimum feature set of SSE2 is required. > > > > Kevin > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *suyog sarda > *Sent:* Thursday, April 09,

The output of the avx-hadd program is 3 11 7 15 Preston -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands Sent: Thursday, September 22, 2011 3:14 PM To: Bruno Cardoso Lopes Cc: LLVMdev Subject: Re: [LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits Hi Bruno, > Some comments:

> On Tue, May 15, 2007 at 01:23:32AM -0700, Tanya M. Lattner wrote: >> 4) Compile llvm-gcc4 and llvm from source. Run 'make check' and do a 'make >> ENABLE_OPTIMIZED=1 TEST=nightly report' in llvm-test. >> >> It would also be helpful for someone to compile/test with objdir != srcdir. > > This is on FreeBSD 6.2-RELEASE, on i386. > Both llvm and

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