[LLVMdev] PIC16TargetAsmInfo::getBSSSectionForGlobal

Alireza.Moshtaghi at microchip.com Alireza.Moshtaghi at microchip.com
Mon Jul 20 16:18:38 PDT 2009

Substituting the uses of a global with an absolute address would make
all accesses to that global through pointer, which is very inefficient
on PIC16. So we don't change the code generation for that global;
instead we only pass the address information to the linker (home made
linker) through some assembly directives.
What are you trying to do? Are you trying to change the logic of this
part or it is only simple refactoring?


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> Behalf Of Chris Lattner
> Sent: Monday, July 20, 2009 3:21 PM
> To: Sanjiv Kumar Gupta - I00171
> Cc: LLVM Developers Mailing List
> Subject: [LLVMdev] PIC16TargetAsmInfo::getBSSSectionForGlobal
> Hi Sanjiv,
> The PIC16TargetAsmInfo::getBSSSectionForGlobal apparently does magic
> that reinterprets the "section" field of a global in a strange way:
>    // If GV has a sectin name or section address create that section
> now.
>    if (GV->hasSection()) {
>      std::string SectName = GV->getSection();
>      // If address for a variable is specified, get the address and
> create
>      // section.
>      std::string AddrStr = "Address=";
>      if (SectName.compare(0, AddrStr.length(), AddrStr) == 0) {
>        std::string SectAddr = SectName.substr(AddrStr.length());
>        S = CreateSectionForGlobal(GV, SectAddr);
>      }
> Why isn't the front-end handling this, replacing all uses of the
> global with the address?  Does PIC allow initializing random sections
> of globals like this?  I need to heavily refactor all this code, and
> since there are no testcases at all for PIC16, I'm afraid of breaking
> something.
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list