search for: globalaliases

On Fri, May 23, 2014 at 3:06 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > > Sent from my iPhone > >> On May 23, 2014, at 17:51, Eric Christopher <echristo at gmail.com> wrote: >> >> I'm not there yet, but at some point I'm going to need the notion of a >> global callable function like symbol that's resolved at

>> > For example, it would not be possible to define an absolute symbol to be >> > the offset between two symbols. In some restricted circumstances — >> > if both symbols are global variables in the same section and defined >> > in the same translation unit — this could be worked around. >> > >> > But I’ll gladly admit that I don’t have a use

I'm not there yet, but at some point I'm going to need the notion of a global callable function like symbol that's resolved at runtime. I've not given it much thought but I may need a new callable entity here (this is for the gnu ifunc stuff). Don't even know if this fits into the discussion, but since we were talking about weird symbols... -eric On Fri, May 23, 2014 at 1:26

> I agree that this accurately summarizes both (1) what’s expressible in > current object file formats and (2) what we’re likely to want to need from > global aliases. > >> The tool we have in llvm for creating these extra labels is the GlobalAlias. >> >> One way of representing the above uses is to be explicit: a label is >> created with a specific value or at

Bringing the discussion to llvmdev. For the purposed of this discussion, object files can be thought as having just a few thing we care about: data, labels and relocations. Data is what at llvm ir would be just the contents of variables or functions. Relocations are utilities to compute the data at link time when it is not possible to do so earlier. For example, to compute a pcrel relocation we

...happens wihout the > getUnderlyingObject() returning the same value. > > It would be nice if someone could produce such a test case, or dismiss > the possibility of this happening. My bad, it seems that while I wasn't looking, someone taught getUnderlyingObject to look through GlobalAliases and return what they point to! However the previous patch was wrong given code like: @gv = global i32 0 define void @test() { store i16 1, i16* inttoptr(i64 add(i64 ptrtoint(i32* @gv to i64), i64 1) to i16*) ; ; Not dead store i32 2, i32* @gv ret void } > Anyway, say...

...sure noaliasAtFunctionEntry makes sense, for two reasons: a) The pointer involved may not be defined at entry. b) We already have something which is similar in spirit - IsIdentifiedObject. That covers the 3 cases I have in the new function, but also two additional ones: GlobalValues which are not GlobalAliases, and byval arguments. Unfortunately, a check of Argument vs. IsIdentifiedObject is too broad, because an argument (which is not noalias) can alias a GlobalValue. Regarding the namespace - I just thought I should keep isNoAliasArgument close to isNoAliasCall. I'll move it to BasicAliasAnalysi...

...for two reasons: > a) The pointer involved may not be defined at entry. Right, I thought of that too. > b) We already have something which is similar in spirit - IsIdentifiedObject. That covers the 3 cases I have in the new function, but also two additional ones: GlobalValues which are not GlobalAliases, and byval arguments. Okay. > Unfortunately, a check of Argument vs. IsIdentifiedObject is too broad, because an argument (which is not noalias) can alias a GlobalValue. Right. IsIdentifiedFunctionLocal? :) > Regarding the namespace - I just thought I should keep isNoAliasArgument close t...

After discussing with Nick Lewycky in the IRC channel, here comes a less aggressive patch. We were worried that a constant pointer could alias with a GlobalValue. Also, if one pointer could be a GlobalValue and the other a GlobalAlias with the GlobalValue as aliasee. However, I was not able to produce a test where this happens wihout the getUnderlyingObject() returning the same value. It

Kuperstein, Michael M wrote: > Thanks Nick! > > Can you just check sanity before I commit? > (Or suggest a better name for the function...) Sure! +static bool canNotAliasDiffArgument(const Value *V) +{ + return (isa<AllocaInst>(V) || isNoAliasCall(V) || isNoAliasArgument(V)); +} Extra parens? The name "canNotAliasDiffArgument" works, but it's named for what we

Dan Gohman wrote: > On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > >> Here is another change I'd like to suggest to the BasicAliasAnalysis. >> >> LLVM fails to remove the dead store in the following code: >> >> %t = type { i32 } >> >> define void @f(%t* noalias nocapture %stuff ) { >> %p = getelementptr inbounds %t* %stuff, i32 0,