search for: globalsummary

The one that doesn’t require global analysis is commit in r324757. The global analysis will require adding a field into GlobalSummary. Let me do some research. The implementation should not be hard but I don’t want to break bitcode compatibility if that applies to the summary. Steven > On Feb 9, 2018, at 9:33 AM, Teresa Johnson <tejohnson at google.com> wrote: > > SGTM. I would do as 2 separate patches, the loca...

...ould just work in ELF as well and would not require LTO. Peter On Fri, Feb 9, 2018 at 10:46 AM, Steven Wu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The one that doesn’t require global analysis is commit in r324757. > > The global analysis will require adding a field into GlobalSummary. Let me > do some research. The implementation should not be hard but I don’t want to > break bitcode compatibility if that applies to the summary. > > Steven > > > On Feb 9, 2018, at 9:33 AM, Teresa Johnson <tejohnson at google.com> wrote: > > SGTM. I would do as 2...

...this with promotion, then it would be very unfortunate: >>> the whole point of these was to allow to "auto-hide". >>> >>> >>> I think thinLTO should handle unnamed_addr and generate auto hide if >>> needed. We can put (local_)unnamed_addr into GlobalSummary and teach >>> thinLTO to add visibility hidden for symbols that satisfies the condition. >>> I don't think this is very hard to do. >>> >>> I don't know if we have a definition for unnamed_addr. Do we treat it >>> local_unnamed_addr that automati...

...> Peter > > On Fri, Feb 9, 2018 at 10:46 AM, Steven Wu via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > The one that doesn’t require global analysis is commit in r324757. > > The global analysis will require adding a field into GlobalSummary. Let me do some research. The implementation should not be hard but I don’t want to break bitcode compatibility if that applies to the summary. > > Steven > > >> On Feb 9, 2018, at 9:33 AM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wr...

...subtleties here. > If we can't do this with promotion, then it would be very unfortunate: the > whole point of these was to allow to "auto-hide". > > > I think thinLTO should handle unnamed_addr and generate auto hide if > needed. We can put (local_)unnamed_addr into GlobalSummary and teach > thinLTO to add visibility hidden for symbols that satisfies the condition. > I don't think this is very hard to do. > > I don't know if we have a definition for unnamed_addr. Do we treat it > local_unnamed_addr that automatically satisfy condition #1? Then promote...

...is, but I can miss some subtleties here. > If we can't do this with promotion, then it would be very unfortunate: the whole point of these was to allow to "auto-hide". I think thinLTO should handle unnamed_addr and generate auto hide if needed. We can put (local_)unnamed_addr into GlobalSummary and teach thinLTO to add visibility hidden for symbols that satisfies the condition. I don't think this is very hard to do. I don't know if we have a definition for unnamed_addr. Do we treat it local_unnamed_addr that automatically satisfy condition #1? Then promote linkonce_odr + unnamed_...

...miss some subtleties here. >> If we can't do this with promotion, then it would be very unfortunate: the whole point of these was to allow to "auto-hide". > > I think thinLTO should handle unnamed_addr and generate auto hide if needed. We can put (local_)unnamed_addr into GlobalSummary and teach thinLTO to add visibility hidden for symbols that satisfies the condition. I don't think this is very hard to do. > > I don't know if we have a definition for unnamed_addr. Do we treat it local_unnamed_addr that automatically satisfy condition #1? Then promote linkonce_odr...

...; If we can't do this with promotion, then it would be very unfortunate: >> the whole point of these was to allow to "auto-hide". >> >> >> I think thinLTO should handle unnamed_addr and generate auto hide if >> needed. We can put (local_)unnamed_addr into GlobalSummary and teach >> thinLTO to add visibility hidden for symbols that satisfies the condition. >> I don't think this is very hard to do. >> >> I don't know if we have a definition for unnamed_addr. Do we treat it >> local_unnamed_addr that automatically satisfy condit...

...btleties here. >>> If we can't do this with promotion, then it would be very unfortunate: the whole point of these was to allow to "auto-hide". >> >> I think thinLTO should handle unnamed_addr and generate auto hide if needed. We can put (local_)unnamed_addr into GlobalSummary and teach thinLTO to add visibility hidden for symbols that satisfies the condition. I don't think this is very hard to do. >> >> I don't know if we have a definition for unnamed_addr. Do we treat it local_unnamed_addr that automatically satisfy condition #1? Then promote linko...

...; If we can't do this with promotion, then it would be very unfortunate: >> the whole point of these was to allow to "auto-hide". >> >> >> I think thinLTO should handle unnamed_addr and generate auto hide if >> needed. We can put (local_)unnamed_addr into GlobalSummary and teach >> thinLTO to add visibility hidden for symbols that satisfies the condition. >> I don't think this is very hard to do. >> >> I don't know if we have a definition for unnamed_addr. Do we treat it >> local_unnamed_addr that automatically satisfy condit...

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 interesting in general because according to the definition > for local_unnamed_addr, the symbol has to be linkonce_odr to be auto hide > as well. ThinLTO promotion can break that as well. > > What do