[LLVMdev] [Propose] Add address-taken bit to GlobalVariable for disambiguation purpose

Hal Finkel hfinkel at anl.gov
Wed Oct 30 11:00:44 PDT 2013


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




More information about the llvm-dev mailing list