similar to: [LLVMdev] JumpThreading and @llvm.dbg.declare()

Hi Eric,   Thanks for patch information. I have checked the patch with my code and I see that it works. But when I extract the variable and check the metadata information to retrieve the scope information, I do not get exact scope, after optimization. As you said that this is a work in progress, so can we expect full version on this in llvm3.3 release ?   Regards, Pankaj  

Hi All,   Due to 'LowerDbgDeclare' call ( as part of 'instruction combining' optimization), a local variable gets declared and initialized inside the basic blocks it is used in. Is there anyway I can avoid this ?   This is with reference with my previous question. http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061644.html     Regards, Pankaj -------------- next part

There was a patch committed the other day that should, at least, work around some of the behavior you describe. Optimized debug info is an area that's being worked on in ToT and previous releases are particularly bad. I'd use that. -eric On Mon, Apr 29, 2013 at 7:02 AM, Pankaj Gode <godepankaj at yahoo.com> wrote: > Hi All, > > Due to 'LowerDbgDeclare' call ( as

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

All, I'm working on an improvement to the inline cost model, but I'm unsure how to proceed. Let me begin by first describing the problem I'm trying to solve. Consider the following pseudo C code: *typedef struct element { unsigned idx; } element_t; * *static inline unsigned char fn2 (element_t *dst_ptr, const element_t *a_ptr, const element_t *b_ptr,

Hm. I assumed that JumpThreading would be the primary factor in optimizing code like this. Guess not. I'll need to look into SimplifyCFG to see what prevents it from doing the same thing to the other loop: https://godbolt.org/z/F6NjdG On Mon, Feb 3, 2020 at 3:09 PM Michael Kruse <llvmdev at meinersbur.de> wrote: > I assumed the LLVM-IR behind the godbolt link represented the C code

On Jul 7, 2011, at 10:15 PM, Carlo Alberto Ferraris wrote: > Nella citazione giovedì 7 luglio 2011 19:41:16, John McCall ha scritto: >> On Jul 7, 2011, at 4:33 AM, Carlo Alberto Ferraris wrote: >>> Il 07/07/2011 11:14, Cameron Zwarich ha scritto: >>>> I haven't read the code in detail, but it looks like JumpThreading at least attempts to thread across indirect

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.

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

I chatted with Jeremy Morse, Orlando, and Stephen Tozer at the dev meeting, and wanted to summarize the conversation for our benefit, and to share it with others. I aim to be brief, so I apologize if these notes aren't as helpful as they could be to folks who weren't present. Three project ideas, by priority: 1. Address https://llvm.org/pr34136, improving quality of variable location info

/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, Coincidentally I've been working to optimize this same case last week. I was struggling a bit to determine where to put this functionality and eventually went for the pragmatic approach of creating an experimental pass. Probably not the eventual solution, but it may provide some useful input to the discussion here. Basically, I experimented with a 'pre-inlining-transform' pass

On 8/7/2017 1:02 PM, Daniel Berlin wrote: > Can someone fill me in on the issue with the dominator tree, > precisely, during inlining? > We now have the capability of quickly keeping it up to date without > too much trouble (it may require pushing it through a bunch of places, > but the actual changes to do should be easy). If I'm not mistaken (which I very well could be

Hi Sanjay, unfortunately that patch does not help in my case. Here's the IR that fails to get fully optimized: target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" define fastcc zeroext i1 @testfunc(i8** noalias nocapture readonly dereferenceable(8)) unnamed_addr { entry-block: %1 = load i8*, i8**

On Tue, Jan 31, 2017 at 3:09 AM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > 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

On May 8, 2008, at 05:50, Matthijs Kooijman wrote: > I've attached two patches. The first, pass-comments.diff adds or > improves the file comments for a number of passes. This patch is > slightly interesting. The second, pass-doc.diff is mostly a yank-put > job and updates Passes.html as follows. Thanks, applied!

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

2017-01-31 16:59 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: > > > On Tue, Jan 31, 2017 at 3:09 AM, Björn Steinbrink <bsteinbr at gmail.com> > wrote: > >> 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

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

Nella citazione giovedì 7 luglio 2011 19:41:16, John McCall ha scritto: > On Jul 7, 2011, at 4:33 AM, Carlo Alberto Ferraris wrote: >> Il 07/07/2011 11:14, Cameron Zwarich ha scritto: >>> I haven't read the code in detail, but it looks like JumpThreading at >>> least attempts to thread across indirect branches. You can either try >>> to fix it or file a