similar to: [LLVMdev] Jump threading pass bug

On Sep 2, 2010, at 8:05 AMPDT, Argyrios Kyrtzidis wrote: > If I use the jump threading pass on the attached IR: > > $ opt before.ll -jump-threading -o - | llvm-dis -o after.ll > > a big chunk gets removed, a chunk that is actually necessary. > ('before.ll' passes the test in webkit, while 'after.ll' fails) > > Can someone take a look ? This is fixed in

The attached .ll files seem equivalent, but the resulting asm from 'opt-fail.ll' causes a crash to webkit. I suspect the usage of registers is wrong, can someone take a look ? $ llc opt-pass.ll -o - .section __TEXT,__text,regular,pure_instructions .globl __ZN7WebCore6kolos1ERiS0_PKNS_20RenderBoxModelObjectEPNS_10StyleImageE .align 4, 0x90

Hi, After building llvm with clang the llvmc tests are failing with: llvmc: Node llc is not in graph Anyone else see this ? (TOT llvm & clang) -Argiris

On Sep 1, 2010, at 6:25 AM, Argyrios Kyrtzidis wrote: > The attached .ll files seem equivalent, but the resulting asm from 'opt-fail.ll' causes a crash to webkit. > I suspect the usage of registers is wrong, can someone take a look ? The difference is that there is a shift right after the multiply, before the divide. In IR, the difference is: %5 = mul nsw i32 %4, %tmp1

Hi, I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it boggles the mind. Below I provide the optimized asm that is produced from

I attached preprocessed files. $ llvm-g++ gcc-RenderBoxModelObject.ii -fno-exceptions -arch x86_64 -O2 -c -o part.o vs $ clang++ clang-RenderBoxModelObject.ii -fno-exceptions -arch x86_64 -O2 -c -o part.o If I compile with clang, it causes a crash to webkit. -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: prepro.zip Type: application/zip Size:

Here's the optimized versions: $ opt -std-compile-opts unopt-pass.ll -o - | llvm-dis -o - [...] define %3 @_ZN7WebCore15GraphicsContext19roundToDevicePixelsERKNS_9FloatRectE(%"class.WebCore::GraphicsContext"* %this, %"struct.WebCore::FloatRect"* %rect) nounwind ssp align 2 { %roundedOrigin = alloca %"class.WebCore::FloatSize", align 4 ;

On Aug 31, 2010, at 11:18 AM, Argyrios Kyrtzidis wrote: > Hi, > > I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it

On Sep 1, 2010, at 9:42 AM, Argyrios Kyrtzidis wrote: > If I compile with clang, it causes a crash to webkit. This should be fixed by r112751, please verify. /jakob

Using MM registers is wrong unless the user has specifically asked for it, which doesn't seem to be the case here. In the awesome MMX architecture, touching an MM register makes subsequent x87 operations fail unless an EMMS instruction is issued first; none of the compilers here are smart enough to insert EMMS instructions in the right places, so the only safe thing is not to use

On Aug 31, 2010, at 1:21 PMPDT, Argyrios Kyrtzidis wrote: > > Just to be clear, are you saying that the fact that, after using llc > on the second IR, the produced asm is using MM registers, indicates > a bug ? Yes. It's not immediately obvious whether it's in the opt or llc, though. Chris was doing work involving <2 x float> and may know about this. >

On Sep 1, 2010, at 6:25 AMPDT, Argyrios Kyrtzidis wrote: > The attached .ll files seem equivalent, but the resulting asm from > 'opt-fail.ll' causes a crash to webkit. > I suspect the usage of registers is wrong, can someone take a look ? Yes, the code here is wrong: > movl (%rbx), %ecx > imull %ecx, %eax This computes h*((int32)%1) in %eax. > shrq $32, %rax

On Sep 1, 2010, at 11:14 AM, Dale Johannesen wrote: > > On Sep 1, 2010, at 6:25 AMPDT, Argyrios Kyrtzidis wrote: > >> The attached .ll files seem equivalent, but the resulting asm from >> 'opt-fail.ll' causes a crash to webkit. >> I suspect the usage of registers is wrong, can someone take a look ? > > Yes, the code here is wrong: > >> movl

Hi, Argyrios Kyrtzidis <kyrtzidis <at> apple.com> writes: > > Hi, > > After building llvm with clang the llvmc tests are failing with: > > llvmc: Node llc is not in graph > > Anyone else see this ? (TOT llvm & clang) It looks like this is due to a bug in clang: // file1.cpp namespace { class Plugin { }; } // file2.cpp namespace { class Plugin {

On Thu, Nov 13, 2014 at 10:59 AM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote: > Could we consider moving the things you listed to shared pointer semantics > ? It will be a simple and clear model; unless someone justifies that it > will be a performance concern to use shared pointers there I don’t think we > need a new and more complex to reason about smart pointer. >

Hi, I am using clang::ToolInvocation class to compile some code in-memory: clang::tooling::ToolInvocation ti ( compilerArgs, new clang::EmitBCAction(), new clang::FileManager(clang::FileSystemOptions()) ); //filename is the name of the source file, e.g. "Somefile.cpp" //sourcecode contains the source of the file ti.mapVirtualFile( filename,

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > I gave it a try and unfortunately it doesn't seem practical to use > CMake-produced VC++ projects. Every time you run CMake so that the VC++ > projects include new files, the entire solution gets rebuilt. I recall some discussion about the behavior you describe on the cmake ml, but can't find it right now. IIRC, once

Hello, Argiris > Any ideas? 1. Make sure, that you don't mix dwarf and stabs debug information. AFAIR, this can really mess the things 2. It can be, that debug information emitted is not correct. This is known open problem. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Argiris Kirtzidis <akyrtzi at gmail.com> writes: > How does updating the CMake produced VC++ project files work ? > I mean: > > -I have CMake produce VC++ project files > -Compile the solution > -Do a svn update and pick up a couple of files > -Have CMake produce new project files > -Now, do I have to rebuild the entire solution again ? AFAIK, it should do the right

Fair enough, you win this round. ;P (Which actually makes me happy as that makes things a lot more consistent and sensible.) -J -------------------------------------------------- From: "Argiris Kirtzidis" <akyrtzi at gmail.com> Sent: Thursday, October 02, 2008 12:32 PM To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] MS C++ gives