llvm dev - Oct 2013 - [LLVMdev] [Propose] Add address-taken bit to GlobalVariable for disambiguation purpose

>> 2) is just for being pedantic :-)
>>
>> One might otherwise argue in this snippet, x apparently does not have
>> its addr taken,
>> however, it's illegal to say  that "x" and "*p"
don't alias.
> Wait, really? I thought that "volatile static int x" just meant
that the value of x was volatile; not that 'x' might spontaneously start
referring to some other memory location.
You are right. I mixed this proposal with a project I did before.
In that project the interface is asymmetric and the return value take 
into account
of concurrent access.

Sorry for being sloppy. Please ignore 2) completely.
>> I'm not quire sure your question. Let me try to answer.
>>
>> In my implementation, I set address_no_taken in
>> lib/Transformation/IPO/GlobalOpt.cpp.
>> In this pass, it tries to see if a global var has its address taken
>> before it tries to optimize
>> the global variable.
>>
>> ModRef is immaterial in this regard.
>>
>> What I'm try to say in "A4"  is that it is really
*troublesome* if we
>> save the
>> addr-taken-analysis result to a analysis-pass (rather than cache the
>> result to
>> GlobalVariable::addr_not_taken).  If we really have to implement this
>> way,
>> we need to at very least implement following two steps:
> Okay, sounds good. IIRC, GlobalsModRef currently (also) determines whether
or not a global has its address taken. It might make sense to unify that logic
with what you're proposing for GlobalOpt, and it seems like it would
definitely make sense to let GlobalsModRef take advantage of the
address_not_taken bit.
I don't read ModRef carefully. I think it make some sense to factor out 
the addr-taken analysis. Such that
other pass can take advantage of it.
>
> Also, as a general note, I don't see why any of this should be
LTO-specific. For variables with local (internal) linkage, we can do the
analysis on a per-module basis, and I don't understand why we currently
don't.
>
> Thanks again,
> Hal
>
>
You can understand from this example: Suppose the a.c b.c comprise the 
program where a.c has some static variable whose address
are not taken.  The addr-taken information collected during stage 
time-stamp-0 cannot be found at time-stamp-1.2.

If we were saving the addr-not-taken info in 
GlobalVariable::not_addr_taken, optimizations in 1.2 will automatically 
benefit from
cached information.

-------------------------------------
time-stamp-0:
    clang *.c -flto -c -o a.o

time stamp 1:
    clang *.o -flto -o a.out

time stamp 1.1):  link a.o b.o into merged.o
time stamp 1.2):  do some optimizations
time stamp 1.3): addr-taken is re-analyzed.
-------------------------------------

On Oct 29, 2013, at 7:11 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>> Also, as a general note, I don't see why any of this should be
LTO-specific. For variables with local (internal) linkage, we can do the
analysis on a per-module basis, and I don't understand why we currently
don't.
>> 
>> Thanks again,
>> Hal
>> 
>> 
> You can understand from this example: Suppose the a.c b.c comprise the
program where a.c has some static variable whose address
> are not taken.  The addr-taken information collected during stage
time-stamp-0 cannot be found at time-stamp-1.2.
> 
> If we were saving the addr-not-taken info in
GlobalVariable::not_addr_taken, optimizations in 1.2 will automatically benefit
from
> cached information.
To answer Hal’s question, I think internal globals already benefit from Shuxin’s
proposed optimization, independent of LTO. Shuxin is only pointing out a
potential additional benefit, either in terms of compile time (not having to
rerun the analysis) or optimization opportunities (for passes that run before
GlobalOpt reruns).

Whether to split address-taken into a separate Analysis is a judgement call.
Conceptually it could make sense as a separate analysis. I think Shuxin is
pointing out that using a flag is a more straightforward approach, simpler to
engineer, and has some potential benefits (although not huge benefits).

Either way, it could still make sense to factor the logic across
GlobalOpt/GlobalModRef if it’s not too messy.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131029/2ff4cdc4/attachment.html>

----- Original Message -----
> 
> 
> 
> On Oct 29, 2013, at 7:11 PM, Shuxin Yang < shuxin.llvm at gmail.com >
> wrote:
> 
> 
> 
> 
> Also, as a general note, I don't see why any of this should be
> LTO-specific. For variables with local (internal) linkage, we can do
> the analysis on a per-module basis, and I don't understand why we
> currently don't.
> 
> Thanks again,
> Hal
> 
> 
> You can understand from this example: Suppose the a.c b.c comprise
> the program where a.c has some static variable whose address
> are not taken. The addr-taken information collected during stage
> time-stamp-0 cannot be found at time-stamp-1.2.
> 
> If we were saving the addr-not-taken info in
> GlobalVariable::not_addr_taken, optimizations in 1.2 will
> automatically benefit from
> cached information.
> 
> 
> To answer Hal’s question, I think internal globals already benefit
> from Shuxin’s proposed optimization, independent of LTO. Shuxin is
> only pointing out a potential additional benefit, either in terms of
> compile time (not having to rerun the analysis) or optimization
> opportunities (for passes that run before GlobalOpt reruns).
Okay; this sounds good. Part of my motivation for asking the question was a
mistake on my part: GlobalOpt is always used, while GlobalModRef is currently
used only during LTO. I don't understand why GlobalModRef is LTO only, but I
think that's a separate topic from this address_not_taken attribute.

To be clear, I'm generally in favor of having such an attribute, under the
conditions that we have a pass that infers the attribute for internal-linkage
variables at the module level (in addition to for all variables during LTO), and
that the attribute is used by some AA that is used by default (not just during
LTO as the current GlobalModRef analysis is). We might want to start using
GlobalModRef as part of the normal module pass manager configuration, or BasicAA
could use the attribute, or both (or something else entirely).

Thanks again,
Hal
> 
> 
> Whether to split address-taken into a separate Analysis is a
> judgement call. Conceptually it could make sense as a separate
> analysis. I think Shuxin is pointing out that using a flag is a more
> straightforward approach, simpler to engineer, and has some
> potential benefits (although not huge benefits).
> 
> 
> Either way, it could still make sense to factor the logic across
> GlobalOpt/GlobalModRef if it’s not too messy.
> 
> 
> -Andy
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory