Displaying 6 results from an estimated 6 matches for "newlinkage".
Did you mean:
getlinkage
2013 May 07
0
[LLVMdev] Feedback required on proper dllexport/import implementation
...change). And some contributors who have not caught up with
your change may still submit patches with the old semantics in mind,
which seems prone to errors.
If you really like your approach, I wonder if it makes sense to rename
the existing linkage type to something different, e.g., OldLinkage to
NewLinkage, so that future patches using hasOldLinkage() will have
to check their codes to make sure they work with the new semantics.
> Hm, I don't think so, because dllimported inline functions must never be
> instantiated, or else you get duplicated symbols. They are only allowed to be
> expa...
2013 Apr 23
2
[LLVMdev] Feedback required on proper dllexport/import implementation
On 23.04.2013 19:10, Gao, Yunzhong wrote:
> I missed the discussion when I implemented dllexport/dllimport for our local tree. I
> essentially implemented your approach#1. I was trying to avoid the various
> external_linkage + some_attribute approaches because it seems that external_linkage
> would imply the external linkage without the dllimport/dllexport semantics, and there
> may
2013 May 07
1
[LLVMdev] Feedback required on proper dllexport/import implementation
...one to errors.
This is irrelevant here. They need to submit patches against ToT, so,
they will need to submit already "new" patches.
> If you really like your approach, I wonder if it makes sense to rename
> the existing linkage type to something different, e.g., OldLinkage to
> NewLinkage, so that future patches using hasOldLinkage() will have
> to check their codes to make sure they work with the new semantics.
The point here is that patches should come with tests. And this is how
we will make sure they will work with "new" semantics.
> I agree. Hmm that is exactly...
2018 Feb 08
1
ThinLTO and linkonce_odr + unnamed_addr
...confirm, for this case I think then that we could add the following
where we promote linkonce_odr to weak_odr (here:
http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionImport.cpp#659):
if (GV.hasLinkOnceODRLinkage() && GV.hasGlobalUnnamedAddr() &&
GlobalValue::isWeakODRLinkage(NewLinkage))
GV.setVisibility(GlobalValue::HiddenVisibility);
Or am I misunderstanding?
> For linkonce_odr local_unnamed_addr, it needs help from linker to do it
> correctly.
>
> Steven
>
>
> --
> Mehdi
>
>
>
>
>>
>> Steven
>>
>>
>> -...
2018 Feb 08
0
ThinLTO and linkonce_odr + unnamed_addr
> On Feb 8, 2018, at 10:28 AM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>
>
> 2018-02-08 9:33 GMT-08:00 Steven Wu <stevenwu at apple.com <mailto:stevenwu at apple.com>>:
>
>
>> On Feb 7, 2018, at 4:03 PM, Mehdi AMINI <joker.eph at gmail.com <mailto:joker.eph at gmail.com>> wrote:
>>
>>
>>
>> 2018-02-07
2018 Feb 08
3
ThinLTO and linkonce_odr + unnamed_addr
2018-02-08 9:33 GMT-08:00 Steven Wu <stevenwu at apple.com>:
>
>
> On Feb 7, 2018, at 4:03 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>
>
> 2018-02-07 12:45 GMT-08:00 Steven Wu <stevenwu at apple.com>:
>
>>
>>
>> On Feb 7, 2018, at 12:36 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>>
>> > But it is