search for: syoyo

Hi Devang, Thanks. Yes, in the case variable i incremented by 1.0f is optimized. I don't know why... Anyway, I've filed this problem into bugzilla(Bug 3299) -- Syoyo On Fri, Jan 9, 2009 at 12:42 AM, Devang Patel <dpatel at apple.com> wrote: > > On Jan 8, 2009, at 4:36 AM, Syoyo Fujita wrote: > >> Hi LLVM-ers, >> >> I'd like to eliminate dead loop with floating point counter using >> LLVM, but the following loop wasn...

...for opt to remove dead loop with floating point counter? I've tested some loop optimization pass, e.g. -licm, -loop-deletion, but nothing takes effect. FYI, gcc -O3 also can't optimize such a loop, but icc -O3 can. LLVM and clang used are recent version from svn. Thanks in advance. -- Syoyo

On Jan 8, 2009, at 4:36 AM, Syoyo Fujita wrote: > Hi LLVM-ers, > > I'd like to eliminate dead loop with floating point counter using > LLVM, but the following loop wasn't optimized by opt. > > void > func() { > float i; > for (i = 0.0f; i < 1000.0f; i += 1.2f) { > } > } FWIW, L...

...ss is dependent on the loop analyses being able to determine that the loop is finite, which they don't attempt to do for loops with floating point indices. Attempting to do so would require additional reasoning about floating point precision issues. --Owen On Jan 8, 2009, at 9:22 AM, Syoyo Fujita wrote: > Hi Devang, > > Thanks. Yes, in the case variable i incremented by 1.0f is optimized. > I don't know why... > Anyway, I've filed this problem into bugzilla(Bug 3299) > > -- > Syoyo > > On Fri, Jan 9, 2009 at 12:42 AM, Devang Patel <dpatel at...

Hi LLVM-ers, I am trying to get a return type of a function(from bitcode file) with LLVM-C API, but there seems no appropriate API to do that. I've tried to do that with following code, ---- LLVMModuleRef M; LLVMMemoryBufferRef MemBuf; LLVMValueRef F; // Function LLVMTypeRef RetTy; char *ErrStr; // // -- Load shader module //

On Jan 14, 2009, at 5:11 AM, Syoyo Fujita wrote: > Thanks for many comments. > > The loop with finite fp values(which could be representable in IEEE754 > fp format) such like, Sure, LLVM could definitely do this. If you're interested, I'd suggest starting by extending the existing code that we have to do t...

Hi Syoyo, > I am trying to get a return type of a function(from bitcode file) with > LLVM-C API, but there seems no appropriate API to do that. From my memory, this info is stored in the function type, so you could look at the function's type and get the info there. Looking the the API docs [1],...

...rs. Good. I am also trying to sending a patch to llvm-commits. It'd be better for me to use [AVX] prefix in the subject so that we can easily identify "This is an AVX patch" to avoid duplicated work? I've sent a fpext codegen patch. Next I am working is sitofp codegen path. -- Syoyo

Ralf Karrenberg <Chareos at gmx.de> writes: > This sounds great! > > For my case, I only require some basic support, so I am optimistic > that your next few patches will provide everything I need. If my evil plan works out, within the next 10 or so patches we should be in a place where pushing everything up goes pretty quickly. It's about 8 TableGen patches and then a

...the overflow) Thus I believe the loop as shown above could be removed safely. FYI, gcc -O3 turns fp loop counter into integer, but gcc does not optimize further(eliminate the loop). $ gcc -O3 floop.c _foo: pushl %ebp movl $834, %eax movl %esp, %ebp .align 4,0x90 L2: decl %eax jne L2 -- Syoyo On Fri, Jan 9, 2009 at 1:11 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > FWIW, I believe icc -O3 turns on the equivalent of -ffast-math by default. > I could be misremembering which compilers do this though :) > This flag allows you to make all kinds of nice simplfiying assum...

FWIW, I believe icc -O3 turns on the equivalent of -ffast-math by default. I could be misremembering which compilers do this though :) This flag allows you to make all kinds of nice simplfiying assumptions about floating point. On Thu, Jan 8, 2009 at 7:45 PM, Owen Anderson <resistor at mac.com> wrote: > I assume it checks that the end condition and the increment can both > be

...ParserOnly = 1 in { defm VCVTSI2SD : sse12_vcvt_avx<0x2A, GR32, FR64, i32mem, "cvtsi2sd">, XD, VEX_4V; ... } If this style of modification is OK for people working on x86/AVX .td, I am ready to provide a patch. Or is there any better way? -- Syoyo

Thanks Syoyo and Bruno for your replies. As suggested, I filed a bug under http://llvm.org/bugs/show_bug.cgi?id=10073 . I am not familiar with .td files and the LLVM backend infrastructure yet, but I might give it a try and solve it myself if I find the time. Best, Ralf Am 02.06.2011 23:55, schrieb Bruno...

Hi Ralf On Wednesday, June 1, 2011, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi, > > The last time the AVX backend was mentioned on this list seems to be > from November 2010, so I would like to ask about the current status. Is > anybody (e.g. at Cray?) still actively working on it? I don't think so! > I have tried both LLVM 2.9 final and the latest trunk, and it

Hi, The last time the AVX backend was mentioned on this list seems to be from November 2010, so I would like to ask about the current status. Is anybody (e.g. at Cray?) still actively working on it? I have tried both LLVM 2.9 final and the latest trunk, and it seems like some trivial stuff is already working and produces nice code for code using <8 x float>. Unfortunately, the backend

Hi Andy, My use case is quite similar to what Keno described. I am using clang + JIT to dynamically compile C++ functions generated in response to user interaction. Generated functions may be unloaded or modified. I would like to break down the old JIT code into three major parts. 1) The old JIT has its own code emitter, which duplicates code from lib/MC and does not generate debug info and