On Jun 5, 2008, at 10:38 AM, Ian Lance Taylor wrote:
Sure. But here's the thing: the gcc LTO approach involves having a
regular object with a regular symbol table, and the IR is embedded
in
the object. In other words, we do know the symbol version
information: it's in the symbol table of the
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote:
>
>> Chris Lattner <[EMAIL PROTECTED]> writes:
>>
>>> I don't know how closely your plans follow this model. If you think
>>> this approach is reasonable, you really do need to reflect things
>>> like
On Jun 5, 2008, at 6:51 AM, Ian Lance Taylor wrote:
Chris Lattner <[EMAIL PROTECTED]> writes:
I don't know how closely your plans follow this model. If you think
this approach is reasonable, you really do need to reflect things
like
symbol versions in your IR somehow. This compiler must
Chris Lattner <[EMAIL PROTECTED]> writes:
> I don't know how closely your plans follow this model. If you think
> this approach is reasonable, you really do need to reflect things like
> symbol versions in your IR somehow. This compiler must know about
> versions, and when it does, it is easy to
On Jun 4, 2008, at 10:39 PM, Ian Lance Taylor wrote:
Devang Patel <[EMAIL PROTECTED]> writes:
If the optimizer can handle the symbol versioning case when one
definition with version is defined in the same source file as the
reference then you don't need new API.
For example,
a.o : refers to S
