search for: polukhin

...gt; Var2 <-> Alias1 <-> Alias2 <-> IFunc1 <-> Ifunc2 and keep FirstFunc, FirstVar, FirstAlias and FirstIFunc pointers. One place where having another list might be a bit annoying is the symbol iterator of IRObjectFile. Cheers, Rafael On 22 December 2015 at 08:23, Dmitry Polukhin <dmitry.polukhin at gmail.com> wrote: > I start prototyping second approach that makes ifunc new type of > GlobalValue. And I would like to reconfirm how much we would like to share > between aliases and ifuncs. For example, should Module have separate lists > of aliases and ifunc...

BTW, I have found why it doesn't work for arrays. TBAA information propagation is not implemented in CodeGenFunction::EmitArraySubscriptExpr with "TODO: Preserve/extend path TBAA metadata?". On Fri, Dec 4, 2015 at 1:38 PM, Dmitry Polukhin <dmitry.polukhin at gmail.com> wrote: > As far as I can see it is specifics of arrays inside structs. Current TBAA > does distinguish non-array members with path sensitive TBAA (see !1 and !6 > in my example below, TBAA has reference to struct !2 and offset). As for > arrays info...

...ossible in the frontend. > > Doing array subscript analysis in general, probably not something you want > in the frontend. > Handling tricky cases of what pointers to structs point to, probably the > domain of field-sensitive points-to > > On Mon, Dec 7, 2015 at 7:13 AM, Dmitry Polukhin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> BTW, I have found why it doesn't work for arrays. TBAA information >> propagation is not implemented in CodeGenFunction::EmitArraySubscriptExpr >> with "TODO: Preserve/extend path TBAA metadata?". &...

...gt;> I would probably go with 2. >>> >>> 3 is particularly undesirable as it make the ifunc really hard to >>> differentiate from an alias. >>> >>> Cheers, >>> Rafael >>> >>> >>> On 18 December 2015 at 13:44, Dmitry Polukhin via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > Hi Everyone, >>> > >>> > I would like to implement GCC ifunc attribute support in Clang and >>> LLVM. At >>> > the moment Clang ignores the attribute with a warning. On...

...ray" or a "C short". > > Thus, while helpful, TBAA info in LLVM tells it *nothing* about the types, > it only tells it that "if i am accessing this offset, it is disjoint with > accessing this other offset". > > > On Tue, Dec 8, 2015 at 3:38 AM, Dmitry Polukhin <dmitry.polukhin at gmail.com > > wrote: > >> Jeroen, thank you for very useful link with the context. Indeed union >> cases are very complicated and I see places in code when TBAA gives up. >> >> Daniel, I completely agree that TBAA has limited power and can sol...

...5 at 11:44 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > I would probably go with 2. > > 3 is particularly undesirable as it make the ifunc really hard to > differentiate from an alias. > > Cheers, > Rafael > > > On 18 December 2015 at 13:44, Dmitry Polukhin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi Everyone, > > > > I would like to implement GCC ifunc attribute support in Clang and LLVM. > At > > the moment Clang ignores the attribute with a warning. On LLVM IR level > > there is no support for...

...estion or push back, I'm going to prepare such patch. Third approach mostly added for completeness. References: - GCC ifunc documentation https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html - IFUNC low-level technical details http://www.airs.com/blog/archives/403 Thanks, Dmitry Polukhin -- Software Engineer Intel Compiler Team -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151218/b5c390b9/attachment.html>

> * Calling getBaseObject() on a GlobalIFunc returns its resolver function. I still don't understand how it can happen looking to the code ( https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Globals.cpp#L430). I believe it should return nullptr (the same as if you call it from GlobalAlias that refers to GlobalIFunc). I don't have a strong opinion here because deriving

Hi, I'm trying to optimize a simple C code and came across a situation where invariant code is not being moved out: On an -O3 compilation, I noticed that the "load" for the loop bounds (which remain invariant throughout) happens on each iteration of both the loops, even though it is not modified anywhere in the function "bigLoop". It seems that alias analysis is not able

On 3 August 2016 at 10:46, Renato Golin <renato.golin at linaro.org> wrote: > We certainly do. This is a big deal. I'll write up something and let > Dmitry correct my mistakes. :) Done. > We'll also add the ARM/AArch64 changelogs. Done. :) cheers, --renato

Please see inline. struct S { >> int a[10]; >> int b; >> }; >> >> int foo(struct S *ps, int i) { >> ps->a[i] = 1; >> ps->b = 2; >> return ps->a[0]; >> } >> >> define i32 @foo(%struct.S* nocapture %ps, i32 %i) #0 { >> entry: >> %idxprom = sext i32 %i to i64 >> %arrayidx = getelementptr