similar to: [LLVMdev] AA bug?

So, i'm working through the last of miniscule gvn optimizations, and one of the things that gets tested is whether it will eliminate non-volatile loads in favor of ohter non-volatile loads when there are volatile loads in the way. I.E. define i32 @test1(i32* nocapture %p, i32* nocapture %q) { entry: %x = load i32, i32* %p %0 = load volatile i32, i32* %q %y = load i32, i32* %p %add =

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009,

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009,

Hi, I am using DataStructureAA.cpp (poolalloc project) for alias analysis purposes and have noticed an error in getModRefInfo(). The situation is that Mod/Ref info is called with a CallSite and GlobalVariable argument, where the global is passed as an argument to the call. Furthermore, the callee function does *nothing* with this global but to pass it on to another callee function. In

On 22-Jul-08, at 1:22 PM, Dan Gohman wrote: > On Jul 21, 2008, at 3:51 PM, Stefanus Du Toit wrote: >> - build a custom alias analysis pass that indicates that these loads >> never alias with any stores in a given function >> - declare these globals as external constants within the module > > If you can convince yourself that no interprocedural optimization > will ever

On Jul 21, 2008, at 3:51 PM, Stefanus Du Toit wrote: > Our frontend can guarantee that loads from globals are > rematerializable and do not alias with any stores in any function in > the given module. We'd like the optimization passes (and ideally the > register allocator as well) to be able to use this fact. The globals > are not constant "forever" but are constant

Hi, I'm having a problem with GVN removing a load instruction that I think is needed. Dump before GVN: *** IR Dump Before Global Value Numbering *** ; Function Attrs: minsize optsize define i16 @TEST__MAIN(i16 %argc.13.par, i16** %argv.14.par) #0 { %buf.17 = alloca [10 x i16], align 1 %_tmp30 = getelementptr inbounds [10 x i16], [10 x i16]* %buf.17, i16 0, i16 0, !dbg !22 call

Duncan, thanks for your answer! > In order to perform this transform the optimizers would have to work out > that sample does not modify any global state.  This cannot be done without > knowing the definition of sample, but you only provide a declaration. Which is why I am trying to supply this additional information in a custom alias analysis pass, but it doesn't seem to work. (The

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >

On Jul 22, 2008, at 2:51 PM, Stefanus Du Toit wrote: > On 22-Jul-08, at 1:22 PM, Dan Gohman wrote: >>> If I apply the patch found further down, LICM moves the loads out >>> (as >>> expected), but of course this is a fairly specific fix. >> >> Slightly better than checking for GlobalVariabls directly >> is to call the AliasAnalysis'

> > Sigh > I should have taken the time to give a better example. > The must-alias part is irrelevant to an example (it only requires > read-onlyness) > > You said "LICM doesn't move calls, so we'd never really care about > must-alias for promotion". I was just pointing out other things move calls > any may want to know. > > If you want an example

On Mon, 15 May 2006, Nai Xia wrote: > In other words, if I only use -steens-aa and the data_XXXs are all > external global variables( and so inComplete ), Sounds right! > the call to printf will > make the same effect, which I have tested it. > > Am I right ? :) If you've tested it then, yes you're right :). I haven't played with this stuff for a long time,

Hi all, While working on a loadable Alias Analysis module pass, I'm running into the following issue: I'm finding my pass queried for results after it has had 'releaseMemory' called on it and its dependencies, but before runOnModule is called again (on my pass or its deps). As you might expect, this makes my pass rather unhappy (and I think correctly so). This happens with LICM

Hi Stephan, > intrinsic float4 sample(int tex, float2 tc); > > float4 main(int tex, float2 tc) > { > float4 x = sample(tex, tc); > return 0.0; > } without additional information it would be wrong to remove the call to sample because it might write to a global variable. > As you can see, the call to the sample function is still present, > although the actual value

> In your new proposal, doing & on the result of getModRef() may yield unexpected results. Agreed. I made the change I proposed locally, and, while it simplifies some cases, it makes other bit-wise operations look unintuitive. > Maybe we should just hide all that in inline functions or something and make it an enum class Noted, and looking into this option. Hoping a couple of static

# The future of the va_arg instruction ## Summary LLVM IR currently defines a va_arg instruction, which can be used to access a vararg. Few Clang targets make use of it, and it has a number of limitations. This RFC hopes to promote discussion on its future - how 'smart' should va_arg be? Should we be aiming to transition all targets and LLVM frontends to using it? ## Background on va_arg

On 9 August 2017 at 19:38, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/9/2017 9:11 AM, Alex Bradbury via llvm-dev wrote: >> >> Option 3: Teach va_arg to handle aggregates >> * In this option, va_arg might reasonably be expected to handle a >> struct, >> but would not be expected to have detailed ABI-specific knowledge. e.g. >> it

Hi! I am trying to implement va_arg() on ppc32. Everything went smooth, except implementing va_arg() of 64bit int. Since i64 is not a legal type on ppc32 DAGTypeLegalizer::ExpandRes_VAARG() splits the va_arg(i64) into two i32 va_args. The problem with ppc32 va_arg is that it needs special "alignment" of its gpr pointer when the argument is i64. Ie. I need to know if I am lowering

Hi all, Would it be correct to say that the only instructions in LLVM IR that modify/access memory potentially are the following: (1) LoadInst : Ref (2) StoreInst : Mod (3) VAArgInst : Ref (?) (4) AllocaInst : Mod (5) MallocInst : Mod (6) FreeInst : Mod (7) CallInst : Mod/Ref ? Also, my earlier impression was that the GEP instruction only computes the effective address and does not

Hi folk, I'm writing a set of small C code to verify whether my pass handle some instruction correctly. One of the instruction I want to test is "va_arg", but compiling my variadic function does not generate any va_arg instruction. Is va_arg deprecated? Will va_arg instruction ever be generated by any front-end? The source code and llvm instructions are appended as follows. the