similar to: [LLVMdev] Problem with PostRASchedulerList.cpp - advice wanted

In the course of implementing the instruction scheduler for the Intel Atom in LLVM, I have run across a problem with the critical anti-dependence breaker, whereby CriticalAntiDepBreak.cpp code changes some XMM0 references to be XMM9 references. This would be all well and good, were it not for the fact that the result of the expression needs to be in XMM0 because it is being returned as the

When trying to run test/CodeGen/X86/liveness-local-regalloc.ll with the command line options "-optimize-regalloc=0 -verify-machineinstrs -mcpu-atom", the test fails right after the Post-RA pseudo instruction pass with the messages *** Bad machine code: Using an undefined physical register *** - function: autogen_SD24657 - basic block: BB 0x2662d60 (BB#0) - instruction:

Using the following example program #include <math.h> double f(double d){ return sqrt(d); } and compiling it with "clang -O3 ...", I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a sqrtsd instruction inline. It turns out that it could do exactly that, were it not for the fact that in the function

My team interested in doing some post-RA optimizations on X86 instructions, which would require identifying memory reference instructions. In the X86 back end instructions, memory addresses consist of a set of five operands. The offset to the start of the five operands depends on the format of the instruction. For instance, the instructions ADC32rm, ADD32rm, AND32rm, ANDN32rm, CMOVA32rm,

On 21.05.2013, at 23:03, "Gurd, Preston" <preston.gurd at intel.com> wrote: > Thanks for the fix! > > However, there still seems to be a problem in that if you pass –ffast-math to clang, then clang changes “sqrt” to be “__sqrt_finite”. LLVM cannot then change the function call into an x86 sqrt instruction, even with –fno-math-errno set. > > Can you suggest

Hello Andy, Thank you for your offer to work together on implementing the your new scheduler on X86. I can start working on this right away. In case you were unaware, the new Silvermont micro-architecture is only out of order on the integer side. The SSE instructions are still in order, so the current postRA scheduler is very beneficial for code with lots of SSE instructions, such as the ISPC

On May 17, 2013, at 3:33 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote: > Using the following example program > > #include <math.h> > > double f(double d){ > return sqrt(d); > } > > and compiling it with “clang –O3 …”, I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a

Since Clang does not seem to allow type casts, such as uchar4 to float4, between vector types, it seems it is necessary to write them as element by element conversions, such as typedef float float4 __attribute__((ext_vector_type(4))); typedef unsigned char uchar4 __attribute__((ext_vector_type(4))); float4 to_float4(uchar4 in) { float4 out = {in.x, in.y, in.z, in.w}; return out; } Running

On Nov 20, 2008, at 8:31 AM, Preston Gurd wrote: > Might you instead consider just adding a -disable-mmx option? I agree, this is a better approach. This distinguishes between capabilities of the chip and the desire to codegen specific vectors one way or another. -Chris > > Preston > > On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: >> Hi, >> >>

Thanks for the fix! However, there still seems to be a problem in that if you pass –ffast-math to clang, then clang changes “sqrt” to be “__sqrt_finite”. LLVM cannot then change the function call into an x86 sqrt instruction, even with –fno-math-errno set. Can you suggest where I might look in the clang code to find the place where “sqrt” is converted to “__sqrt_finite” and/or the best way to

Does fast-math imply no-math-errno ? Thanks, Nadav On May 17, 2013, at 15:36, Chris Lattner <clattner at apple.com> wrote: > > On May 17, 2013, at 3:33 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote: > >> Using the following example program >> >> #include <math.h> >> >> double f(double d){ >> return sqrt(d);

Might you instead consider just adding a -disable-mmx option? Preston On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: > Hi, > > When setting -mattr option on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of John Criswell Sent: Tuesday, September 11, 2012 1:42 PM To: Steve Checkoway Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Need Help Understanding Operands in X86 MachineFunctionPass ... > >> The code for adding the 32-bit instruction is: >> >>

-- Preston Gurd <preston.gurd at intel.com> Intel Waterloo SSG/DPD/ECDL/DMP -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120409/b78a88d6/attachment.html>

Hi, When setting -mattr option on X86, I would like to treat MMX separately from SSE levels. This would allow a client who sets the attributes directly to set the SSE level independent of MMX, e.g., llc -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If anyone objects to this change, please let me

Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to generate the patch file against revison 167719 ? Thanks in advance. On

Preston, thanks for the explanation and patch. Now it's printing the direction and distance values. On Tue, Nov 13, 2012 at 12:22 PM, Preston Briggs <preston.briggs at gmail.com>wrote: > Erkan, you're right. Sorry about that. > Attached is the most recent version. > > Preston > > > > Hi Preston, >> I am trying to use DA as well. I used your example

On 13.11.2012, at 10:46, erkan diken <erkandiken at gmail.com> wrote: Hi all, Unfortunately, all my Hunks are failed when I apply : patch -p1 < da.patch command. The problem might be due to the fact that da.patch file was created against revision 167549, but I am on revision 167719 (I believe the most recent one). I am not sure if this cause the problem ? But Preston may I ask you to

Erkan, you're right. Sorry about that. Attached is the most recent version. Preston Hi Preston, > I am trying to use DA as well. I used your example and commands that you > wrote in order to get DA information. > However, it does not report any dependence info. > I am wondering whether your local copy differs from the one on the > repository ? > Thanks. > Erkan.

> On Sep 10, 2018, at 5:25 PM, Matthias Braun <mbraun at apple.com> wrote: > > > >> On Sep 10, 2018, at 5:11 PM, Preston Briggs <preston.briggs at gmail.com <mailto:preston.briggs at gmail.com>> wrote: >> >> The phi instruction is irrelevant; just the way I think about things. >> The question is if the allocator believes that t0 and t2