search for: maybeoverridden

..., as this global is accessed before the dynamic loader initialises the GOT. However, LLVM sees through the alias and resolves references to _rtld_local to _rtld_global, resulting in segfaults when the dynamic loader is used. I'm trying to figure out the best way to fix this. The GlobalValue::mayBeOverridden() function controls whether LLVM resolves aliases, and hacking this function to return true if a global is hidden gets around this particular problem, but converts the function into a misnomer (a hidden alias may _not_ be overridden, e.g. by LD_PRELOAD, although I'm pretty sure mayBeOverridden...

...ferent inside our JVM because of the way we register dependencies, but I'm trying to make a LLVM-centric argument here.) At this point, I think it is most straightforward to do a slight variant of what Philip suggested to me offline: if a function can deoptimize, it needs to be marked as "mayBeOverridden", preferably by introducing a new function attribute or by setting the linkage type to one of those checked by GlobalValue::mayBeOverridden. This is the responsibility of the frontend, and resuming to the "deopt" continuation in a physical frame where the enclosing function was not...

...hat the problem was more general than the one > > case above). > > ^ This particular case above is already fixed in DeadArgElim: > Fascinating. So I'm just proposing that we need to use similar logic in other IPO passes. We should probably factor it. Maybe we just need to admit mayBeOverridden in more cases. It's not clear that there is any meaningful delta between what has been discussed and just putting these cases into that set. -Chandler > > bool DAE::RemoveDeadArgumentsFromCallers(Function &Fn) > { > // We cannot change the arguments if this TU does not defi...

On Thu, Feb 25, 2016 at 9:59 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Couple of other examples: > > void @foo(i32* %ptr) available_externally { > %discard = load i32, i32* %ptr > } > void bar() { > call @foo(i32* %x) > } > > ==> > > void @foo(i32* %ptr) available_externally { > } > void bar() { >

Hi Alastair, > Forgive my confusion, but I can't help notice that LangRef states: > > Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be

...at we need to use similar logic in > other IPO passes. Yeah, so far I don't see any way around it. Refinement is everywhere, and even if we are able to audit it out *now*, keeping it out will be a major burden. -- Sanjoy > > We should probably factor it. Maybe we just need to admit mayBeOverridden in > more cases. It's not clear that there is any meaningful delta between what > has been discussed and just putting these cases into that set. > > -Chandler > >> >> >> bool DAE::RemoveDeadArgumentsFromCallers(Function &Fn) >> { >> // We canno...

Hi Duncan- Forgive my confusion, but I can't help notice that LangRef states: Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be discarded. Why

...It will not show up in the object file and exists just so one can access an external symbol in a different way (avoid a PLT for example). * Document that if an alias points to a isWeakForLinker symbol, then it must be present in every TU that has the symbol. * Require that aliases do not point to mayBeOverridden aliases. Given that they are implemented by having multiple symbols at the same address, there is no way to implement other semantics. For example, we cannot in an object file represent the semantics of @f = alias weak bitcast (void ()* @g to void (...)*) @h = alias void (...)* @f define void @g()...

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

This is a proposal to add guard intrinsics to LLVM. Couple of glossary items: when I say "interpreter" I mean "the most conservative tier in the compilation stack" which can be an actual interpreter, a "splat compiler" or even a regular JIT that doesn't make optimistic assumptions. By "bailing out to the interpreter" I mean "side exit" as