similar to: [LLVMdev] GVNPRE /PRE is not effective

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:

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

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

I've been looking at GlobalAddress lowering strategy recently and was wondering if anyone had any ideas, insights, or experience to share. ## Background When lowering global address, which is typically done in FooTargetLowering::LowerGlobalAddress you have the option of folding in the global offset into the global address or else emitting the base globaladdress and a separate ADD node for the

On Wed, Oct 19, 2011 at 3:24 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > >> >> On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> >> As for why it should be an IR pass, mostly because once the selection >>> dag runs through the code, we can never

It seems the GVNPRE pass has been removed from the main trunk, though it is present in the 2.6 release. From the llvm-commits archive, I found that it was removed  with this checkin: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090928/088214.html "remove the GVNPRE pass. It has been subsumed by the GVN pass." Does the GVN pass optimize all the partial redundancies

I recently noticed a difference between the way GCC and LLVM treat sign extension for parameters and return values on x86-64. I could not find a clear answer in the x86-64 ABI [1] concerning whether parameters should be sign extended by the caller or callee and similarly whether return values should be sign extended by the caller or callee. Consider a simple 'signed char' division

Hello, I am doing a course project of "Adding the strength reduction in existing GVNPRE implementation". But the problem which I am facing is that for many sample programs I tried, the "gvnpre" pass of opt doesn't perform PRE and it leaves the code as it is. This is my sample program and it should do PRE on it but opt is not performing it. Kindly help me out in this part.

Hi, I have a program as: int main(int argc, char **argv) { int a,b,k,l; scanf("%d%d",&a,&b); if (argc > 1) { k=a+b; } else { k=5; } l=a+b; printf("%d,%d",k,l); return 0; } Now i run the following on it: llvm-gcc -O1 -emit-llvm -c -o 1.bc 1.c llvm-dis 1.bc -o 1.ll opt

On Wed, Feb 8, 2012 at 6:49 PM, Meador Inge <meadori at gmail.com> wrote: > I recently noticed a difference between the way GCC and LLVM treat > sign extension for parameters and return values on x86-64.  I could > not find a clear answer in the x86-64 ABI [1] concerning whether > parameters should be sign extended by the caller or callee and > similarly whether return values

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

Am 03.03.2015 um 19:49 schrieb Philip Reames <listmail at philipreames.com>: Hi Philip first thanks for your response, > You'll need to prove a bit more information to get any useful response. Questions: > 1) What's you're use case? Are you using clang to compile C code? Are you manually generating LLVM IR? yes the "inline function C code" will be compiled

Hi Daniel, Got it. If that's the case, can I implement it under the guidance of your insights/prototype? I think I can spend more time on implementation. Thanks, Taewook ________________________________ From: Daniel Berlin <dberlin at dberlin.org> Sent: Tuesday, April 4, 2017 9:41:30 PM To: Taewook Oh Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [NewGVN] Plan for GVNPRE? Of

Hi Daniel, Thank you for your detailed reply, and thank you for working on GVNPRE. I’d more than happy to test/evaluate it with our benchmark once it is ready. Please let me know if you need any help. Thanks, Taewook From: Daniel Berlin <dberlin at dberlin.org> Date: Tuesday, April 4, 2017 at 6:13 PM To: Taewook Oh <twoh at fb.com> Cc: "llvm-dev at lists.llvm.org"

I suspect this is a straight forward problem so I thought I'd ask. I'm developing a new backend. I recently updated from the LLVM repository and now my output assembly is branching to labels/blocks that have been removed. It had been working fine two weeks ago. What looks suspicious is the following message: TryTailMergeBlocks: BB#1, BB#3, BB#4 Looking for common tails of

Duncan Sands wrote: > Hi Nicolas, > > >> In order to have exceptions for non-call instructions (such as sdiv, >> load or stores), I'm modifying codegen so that it generates a BeginLabel >> and an EndLabel between the "may throwing" instruction. This is what the >> codegen of an InvokeInst does. >> > > the rule is that all

I am looking for guidance on how to: 1.

The Problem? Nowaday, SCEV called "Scalar Evolution" does only evolate instructions that has predictable operand, Constant-Based operand. such as that can evolute as a constant. otherwise we couldn't evolate it as SCEV node, evolated as SCEVUnknown. important thing that we remember is, we do not use SCEV only for Loop Deletion, which that doesn't really needed on nature loops

Hi I have some inline function C code, that llvm could be optimizing better. Since I am new to this, I wonder if someone could give me a few pointers, how to approach this in LLVM. Should I try to change the IR code -somehow- to get the code generator to generate better code, or should I rather go to the code generator and try to add an optimization pass ? Thanks for any feedback. Ciao

All, If we can speculatively execute a load instruction, why isn’t it safe to hoist it out by promoting it to a scalar in LICM pass? There is a comment in LICM pass that if a load/store is conditional then it is not safe because it would break the LLVM concurrency model (See commit 73bfa4a). It has an IR test for checking this in test/Transforms/LICM/scalar-promote-memmodel.ll However, I have