similar to: [LLVMdev] Argpromotion improvements (and fix for PR 2498)

Hi all, I have the following C code. static int addp(int *c, int a,int b) { int x = *c + a + b; return(x); } I want to replace *c with a scalar. So I tried the -argpromotion pass. However, it fails to do anything to the resulting llvm file. List of commands: clang add.c -c -o add.bc clang add.c -S -o add.ll opt -argpromotion -stats add.bc -o add_a.bc llvm-dis < add_a.bc > add_a.ll Also,

Hi, the ArgumentPromotion pass replaces aggregrate function arguments by multiple individual arguments. The default pass only does this when the aggregrate has 3 or less elements, otherwise the code will be unchanged. I have a need to always promote aggregrate arguments, even when there are a lot of them. The attached patch adds a "maxElements" argument to ArgPromotion's

> To clarify, we're trying to provide this invariant on the "ref" graph or > on the graph with direct calls only? I think the invariant need only apply > to the former > More clarification needed :) What do you mean by 'invariant need only apply to the former'? > if we're relying on this for correctness (i.e. an analysis must visit all > callees

Hi Dan, > The requirement to update all callers' call instructions when a callee > gets a new return value is also present in the current MRV-mechanism > with getresult. It's not been a problem we've worried about so far. I didn't mean you can get away without updating your calllers, I'm just saying it could be a bit easier. > Can you give some background about

Hi Chris & Evan, On Sun, Jul 13, 2008 at 03:34:03PM -0700, Chris Lattner wrote: > Why? What value does that provide? Struct indices are not allowed to > be variable, so picking any width constant (that isn't too small) is > fine. What problem are you trying to solve here? The current code only allows 32 bit constants. My patch allows any width constant to be used, but it

Hi Matthijs, Changing PromoteCastOfAllocation to not replace aggregate allocas with non-aggregate allocas if they have GEP users sounds reasonable to me. Finding the maximum alignment is sometimes still useful though, so it would be nice to update the alignment field of the alloca even if its type is left unchanged. Dan On Sep 8, 2008, at 8:57 AM, Matthijs Kooijman wrote: > Hi all, >

Hi all, I'm currently running into some problems with instcombine changing the type of alloca instructions. In particular, the PromoteCastOfAllocation looks at any allocation instruction that is used by a bitast. It does a few checks, but basically tries to change the type of the alloca instruction to the type pointed to by the bitcasted type. The current heuristic for determining if this is

Hi all, currently, GetElementPtrInst has a method getIndexedType, which has a templated variant. You pass in a begin and an end iterator, and it will find the indexed type for those. However, both iterators must iterate over Value*. For some argpromotion code, I would like to pass in iterators that iterate over unsigneds instead of Value*. I currently solve this by transforming my

Dear all, I would like to use the PostDominatorTree in ArgPromotion. I did not find an example of how to use function level analysis inside CallGraphSCCPass. I tried to follow an example of how to use function-level pass in a module pass, but I hit "llvm_unreachable" in PMDataManager::addLowerLevelRequiredPass. What would be a proper way to make PostDominatorTree available in

Jack Howarth wrote: > I've had better luck compiling all of pymol 1.1r2 with > -O4 on darwin9. Everythink links and there appears to be > no regressions in the resulting code. I take it that LTO > in llvm 2.5 is still limited to dead code elimination, > correct? No. libLTO does the equivalent to opt -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine

Hi all, I was looking at the StructRetPromotion pass this morning and noticed it doesn't look at a function's linkage at all. Since it changes the signature of the function, I would say it should only change internal functions, like ArgumentPromotion does for example. Is there some implicit check I'm missing, or should an explicit check really be added? Gr. Matthijs --------------

The 'disable_cb' callback is designed as an optimization to tell the host we don't need callbacks now. As it is not reliable, the debug check is overzealous: it can happen on two CPUs at the same time. Document this. Even if it were reliable, the virtio_net driver doesn't disable callbacks on transmit so the START_USE/END_USE debugging reentrance protection can be easily tripped

The 'disable_cb' callback is designed as an optimization to tell the host we don't need callbacks now. As it is not reliable, the debug check is overzealous: it can happen on two CPUs at the same time. Document this. Even if it were reliable, the virtio_net driver doesn't disable callbacks on transmit so the START_USE/END_USE debugging reentrance protection can be easily tripped

I've gotten a fantastic bug report. Consider the LLVM IR: target triple = "x86_64-unknown-linux-gnu" define internal i8* @access({ i8* }* %arg, i64) { ret i8* undef } define i8* @g({ i8* }* %arg) { bb: %tmp = alloca { i8* }*, align 8 store { i8* }* %arg, { i8* }** %tmp, align 8 br i1 undef, label %bb4, label %bb1 bb1: %tmp2 = load { i8* }*, { i8* }** %tmp, align 8

On Jun 2, 2008, at 1:03 PM, Matthijs Kooijman wrote: >> Can you give some background about what kinds of things you're >> thinking >> about for this? > For example, when I have a function returning {i32, i32} and I want > to add > another i32 to that. If this was a function that simply returns two > i32 > values, any caller will only use extractvalue on

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some

Hello guys, For single scalar pointer parameter, we have 'byval' to specify the pointee is not changed. But for base+range parameters like: declare void @_gfortran_transfer_integer_write(%struct.__st_parameter_dt*, i8*, i32) (This is the fortran runtime api to 'printf' one integer) The 2nd & 3rd args are used to specify the memory of that integer. I didn't find a

Hi Mikhail, As Brian noted, stuff like this works better in the new pass manager. Even in the old pass manager I thought it should work though. Did you initialize the pass, via `INITIALIZE_PASS_DEPENDENCY(PostDominatorTreeWrapperPass)`? Did you require it, via ` AU.addRequired<PostDominatorTreeWrapperPass>();`? Btw. May I ask what you are planning to do? Cheers, Johannes On 01/07,

On Fri, Oct 27, 2017 at 1:50 AM, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This seems slightly inverted. As I understand it, the root of the problem > is that some standards, such as C, C++, and POSIX, define some functions as > special and we rely on their specialness when optimising. Unfortunately, > the specialness is a property of the source

instcombine doesn't seem to be doing it. From my testing it seems to only occur when I use -indvars after a long string of commands. For example: llvm-as < test_fc_27.ll | opt -preverify -domtree -verify -lowersetjmp -raiseallocs -simplifycfg -domtree -domfrontier -mem2reg -globalopt -globaldce -ipconstprop -deadargelim -instcombine -simplifycfg -ba siccg -prune-eh -inline