llvm dev - Jun 2009 - [LLVMdev] Localizing Globals ?

Eli Friedman wrote:
> On Tue, Jun 16, 2009 at 2:35 AM, Sanjiv Gupta<sanjiv.gupta at
microchip.com> wrote:
>   
>> What if my global variable was into a different address space than
stack?
>>     
>
> It doesn't matter in terms of semantics: because AnalyzeGlobal
> returned false, we're guaranteed the address of the global is never
> taken.  I wouldn't be surprised if we end up generating invalid IR in
> some cases, though, because of the semantics of replaceAllUsesWith.
> Do you have a testcase that breaks?
>
>   
The problem is replaceAllUsesWith asserts for type mismatch here. Try 
attached .bc with llvm-ld.

assert(New->getType() == getType() &&
         "replaceAllUses of value with new value of different type!");

Since stack is always on address space zero, I don't think that type of 
GV in a different address space is ever going to match.
The other way is to allow replaceAllUsesWith to ignore address spaces 
while comparing types. (do we have  a way to do that ?).
But then such an optimization may fail the entire idea of user wanting 
to place a variable into different memory space. The original idea of 
user might be to save on the stack space (data memory) and hence he 
asked the variable to be placed into different memory space (program 
memory). So the best bet here is to deny this optimization by checking

GV->getType()->getAddressSpace() == 0.

- Sanjiv


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.bc
Type: application/octet-stream
Size: 1496 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/5068f2aa/attachment.obj>

On Tue, Jun 16, 2009 at 9:12 PM, Sanjiv Gupta<sanjiv.gupta at
microchip.com> wrote:
> The problem is replaceAllUsesWith asserts for type mismatch here. Try
> attached .bc with llvm-ld.
>
> assert(New->getType() == getType() &&
>        "replaceAllUses of value with new value of different
type!");
Ah, right; it probably isn't worth the effort to fix this
transformation to work with alternate address spaces.
> But then such an optimization may fail the entire idea of user wanting to
> place a variable into different memory space. The original idea of user
> might be to save on the stack space (data memory) and hence he asked the
> variable to be placed into different memory space (program memory). So the
> best bet here is to deny this optimization by checking
>
> GV->getType()->getAddressSpace() == 0.
Yeah, that sounds good; mind putting together a patch?

-Eli

>> But then such an optimization may fail the entire idea of user wanting
to
>> place a variable into different memory space. The original idea of user
>> might be to save on the stack space (data memory) and hence he asked
the
>> variable to be placed into different memory space (program memory). So
the
>> best bet here is to deny this optimization by checking
>>
>> GV->getType()->getAddressSpace() == 0.
>>     
>
> Yeah, that sounds good; mind putting together a patch?
>
> -Eli
>
>   
Checked in.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>