[LLVMdev] Where does llvm.memcpy.i64 and friends get lowered ?

Aaron Gray aaronngray.lists at googlemail.com
Sun Jul 19 15:24:52 PDT 2009


2009/7/19 Chris Lattner <clattner at apple.com>

>   On Jul 19, 2009, at 12:43 PM, Aaron Gray wrote:
>
> 2009/7/19 Chris Lattner <clattner at apple.com>
>
>>
>>  On Jul 19, 2009, at 8:35 AM, Aaron Gray wrote:
>>
>>  I am getting a simular problem with ___main appearing if '@main' is used
>> but there is no instance of it in the Module iterators, only in the
>> relocations.
>>
>> Is it possible to do something about these 'ghost symbols' and have them
>> defined in Module. Rather than having to check for them and pick them up
>> when processing relocations.
>>
>>
>> You should not be walking the module.
>>
>
> How else do you get the right symbol info ?
>
>
> You see symbol definitions and references come through the code generator.
>
>  But as I have said lowering functions donot generate there substitute
> value symbols in the Module. They just magically appear in the relocations
> without being in the module. This is a design flaw in LLVM.
>
>
> You do not understand how the code generator works.
>
>  I have done a hack in the COFF writer's relocation code to get round this
> for now. But it does not work very well with symbol indexes.
>
> But am thinking of doing a cleanup pass, or walk the module to get this
> info.
>
> What do you mean "You should not be walking the module." ?
>
>
> You should not walk the function list of the module.  You should not use
> Module* for anything other than handling file scope inline asm and walking
> the global variables.
>


Okay.

Yeah, it just the order semantics of writing COFF files, it would have been
nice to have everything upfront. Although when its rewritten using the DOE
design, generation and writing will be separated and things will be neater
and easier.

Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090719/10dda8f6/attachment.html>


More information about the llvm-dev mailing list