search for: instructioncombiner

/Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/ InstructionCombining.cpp: In member function ‘llvm::Instruction*<unnamed>::InstCombiner::visitAnd (llvm::BinaryOperator&)’: /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/ InstructionCombining.cpp:3597: warning: ‘RHSCC’ may be used uninitialized in this function /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/

Hi all, The InstructionCombining pass causes alignment of globals to be ignored. I've attached a replacement of Fibonacci.cpp which reproduces this (I used 2.3 release). Here's the x86 code it produces: 03C20019 movaps xmm0,xmmword ptr ds:[164E799h] 03C20020 mulps xmm0,xmmword ptr ds:[164E79Ah] 03C20027 movaps xmmword ptr ds:[164E799h],xmm0 03C2002E

On Mon, Feb 23, 2015 at 2:17 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Francois Pichet" <pichet2000 at gmail.com> > > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Sunday, February 22, 2015 5:34:11 PM > > Subject: [LLVMdev] Question about shouldMergeGEPs in

Hello I am not sure I understand the logic for merging GEPs in InstructionCombining.cpp: static bool shouldMergeGEPs(GEPOperator &GEP, GEPOperator &Src) { // If this GEP has only 0 indices, it is the same pointer as // Src. If Src is not a trivial GEP too, don't combine // the indices. if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() &&

Hi, This is regarding a TODO mentioned in getIdentityValue function in InstructionCombining.cpp file. //TODO: We can handle other cases e.g. Instruction::And, Instruction::Or etc. I wanted to know what could be the use cases of implementing these. When I tried implementing these and wrote test cases for the same, the test cases would be optimized in InstructionSimplify before hitting the code

I think I found it. In InstCombiner::ComputeMaskedBits we have the following lines: if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { unsigned Align = GV->getAlignment(); if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); It assumes that global

InstCombine says in its getAnalysisUsage that it preserves the CFG, but for the 4th argument in its INITIALIZE_PASS call, it says false, which I believe corresponds to whether it preserves the CFG. Is this a mistake, or is there deeper meaning here? InstructionCombining.cpp:73-82 char InstCombiner::ID = 0; INITIALIZE_PASS(InstCombiner, "instcombine", "Combine

If you're able to reproduce the infinite loop with -O3 then you should be able to dump out the IR that causes `opt -instcombine` to infloop, unless the bug is truly esoteric (e.g. only caused by a specific use-list ordering). Maybe take a closer look at the output from `opt -print-before-all -O3`? Alternatively you can use bugpoint to minimize the IR to get a small reproducer that causes

At 2013-09-09 13:07:07,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/09/2013 05:18 AM, Star Tan wrote: >> >> At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: >> >>> On 09/08/2013 08:03 PM, Star Tan wrote: >>> Also, I wonder if your runs include the dependence analysis. If this is >>> the

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Francois Pichet" <pichet2000 at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "chandlerc" <chandlerc at gmail.com> > Sent: Tuesday, February 24, 2015 11:27:43 PM > Subject: Re: [LLVMdev] Question about

Hello all, I have evaluated the compile-time and execution-time performance of Polly canonicalization passes. Details can be referred to http://188.40.87.11:8000/db_default/v4/nts/recent_activity. There are four runs: pollyBasic (run 45): clang -O3 -Xclang -load -Xclang LLVMPolly.so pollyNoGenSCEV (run 44): clang -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-codegen-scev

Hi Michael, > InstCombine says in its getAnalysisUsage that it preserves the CFG, > but for the 4th argument in its INITIALIZE_PASS call, it says false, > which I believe corresponds to whether it preserves the CFG. that argument should be set to true if the pass only looks at the CFG, i.e. whatever it computes/does is only a function of the CFG, and doesn't otherwise depend on what

Hi Bill- For what it's worth, a simple truth table proves Chris correct. Alastair On 5 Jan 2010, at 02:46, Bill Wendling wrote: > On Jan 3, 2010, at 10:04 PM, Chris Lattner wrote: > >> Author: lattner >> Date: Mon Jan 4 00:03:59 2010 >> New Revision: 92458 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=92458&view=rev >> Log: >>

Hi Nicolas, > if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { > > unsigned Align = GV->getAlignment(); > > if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) > > Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); > > It assumes that global values are always optimally

Hi Duncan, I see. I didn't know GlobalValue had a method for changing the alignment (and that 0 meant natural alignment). Explicitly calling setAlignment works like a charm. So it's not an LLVM bug. Thanks, Nicolas -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Thursday, 10 July, 2008 14:41 To: llvmdev at cs.uiuc.edu Cc: Nicolas Capens Subject: Re:

On Thursday 10 July 2008 07:46, Nicolas Capens wrote: > Hi Duncan, > > I see. I didn't know GlobalValue had a method for changing the alignment > (and that 0 meant natural alignment). Explicitly calling setAlignment works > like a charm. Nicolas, Where are you explicitly calling setAlignment? From llvm-gcc code? -Dave

Hi Sanjay, 2017-01-30 22:22 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: > My minimal patch idea is to ease the restriction in ShouldChangeType > because i1 is special. I tried the patch below, and it works on the > example...and nothing in 'make check' failed. :) > Yeah, that would work for me as well, I just wasn't sure about the implications that has.

Hi all. Guys in accordance to PR1255 I need to add case-ranges support for passes listed in subject. Who can review some of these passes in nearest future? Thanks! -Stepan.

ISSUE: This code: %bob = type { int } int %alias() { %pbob1 = alloca %bob %pbob2 = getelementptr %bob* %pbob1 ;pbob2 aliases pbob1 %pbobel = getelementptr %bob* %pbob2, long 0, ubyte 0 %rval = load int* %pbobel ret int %rval } Crashes when run through opt -instcombine. InstCombiner visits instructions in reverse declaration order, but

Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity I mainly care about the compile-time and execution time impact for the following cases: pBasic (run 45): clang -O3 -load LLVMPolly.so pNoGenSCEV (run 44): clang -O3 -load LLVMPolly.so -polly-codegen-scev -polly -polly-optimizer=none -polly-code-generator=none pNoGenSCEV_nocan (run 47): same option