similar to: [LLVMdev] Bug in InstructionCombining.cpp

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

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

ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at least in CSIL) unfortunately does not have stdint.h, but it does have the old inttypes.h - and so does Linux. ACTION: In

/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/

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

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

Chris Lattner wrote: >>ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and >>InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes >>from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, >>but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at >>least in CSIL) unfortunately does not have stdint.h, but it does

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

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 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: >>

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 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.

----- 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

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

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

----- Original Message ----- > From: "Jingyue Wu" <jingyue at google.com> > To: "Daniel Berlin" <dberlin at dberlin.org>, "Mark Heffernan" <meheff at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 13, 2015 1:31:59 PM >

On Fri, Mar 13, 2015 at 10:16 AM Mark Heffernan <meheff at google.com> wrote: > On Thu, Mar 12, 2015 at 2:34 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> It is not clear to me at all that preventing the merging is the right >> solution. There are a large number of analysis, including alias analysis, >> and optimizations that use GetUnderlyingObject, and

I think it would make sense for (1) and (2). I am not sure if (3) is feasible in instcombine. (I am not too familiar with LoopInfo) For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to: if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false;