search for: fsemant

Displaying 15 results from an estimated 15 matches for "fsemant".

Did you mean: hemant
2016 Nov 29
2
RFC: Add an "interposible" linkage type (and implement -fsemantic-interposition)
...r" <rnk at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, November 29, 2016 11:34:56 AM > Subject: Re: [llvm-dev] RFC: Add an "interposible" linkage type (and > implement -fsemantic-interposition) > On Tue, Nov 29, 2016 at 9:15 AM Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org > wrote: > > I think that all makes sense. You're just adding the missing > > non-ODR > > conterpart of 'external' linkage. I could imagine having...
2016 Mar 11
3
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...ute__((visibility(“protected”))) on a strong definition would just map >> to ordinary non-hidden external linkage, which the backend would turn into >> STV_PROTECTED. >> >> __attribute__((visibility(“default”))) on a strong definition would map the >> same way unless -fsemantic-interposition was enabled. >> >> The point of removing protected visibility is that we don’t actually honor >> default visibility in the ELF sense, so it’s silly to pretend that LLVM >> visibility is the same as ELF visibility. ELF protected visibility is basically >&...
2016 Mar 11
2
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...xternal or weak_for_linker symbols. __attribute__((visibility(“protected”))) on a strong definition would just map to ordinary non-hidden external linkage, which the backend would turn into STV_PROTECTED. __attribute__((visibility(“default”))) on a strong definition would map the same way unless -fsemantic-interposition was enabled. The point of removing protected visibility is that we don’t actually honor default visibility in the ELF sense, so it’s silly to pretend that LLVM visibility is the same as ELF visibility. ELF protected visibility is basically the semantics LLVM already assigns to def...
2019 Dec 17
2
RFC: Safe Whole Program Devirtualization Enablement
...s mercilessly breaking overrides via LD_PRELOAD, etc.) and I don't see how virtual functions are any different. I think default LLVM behavior needs to be consistent for all inter-procedural optimizations (be it inlining, devirtualization or cloning). Maybe it's time to resurrect Hal's -fsemantic-interposition flag and use it consistently throughout compiler? Users who need GCC-like semantics will be able to employ this flag to prevent unsafe optimizations. -I
2016 Nov 29
0
RFC: Add an "interposible" linkage type (and implement -fsemantic-interposition)
...current behavior is the most-useful behavior and we should keep the current behavior (at least as a default). I do understand, however, that there are valid use cases for ELF interposition and places where we should allow it (e.g. when compiling certain system libraries). GCC recently added a flag -fsemantic-interposition/-fno-semantic-interposition, where using -fno-semantic-interposition provides Clang/LLVM's behavior of assuming that ELF interposition will not be used. It has been suggested that, to be self consistent, LLVM should emit global symbols with protected ELF visibility in cases wh...
2019 Dec 18
2
RFC: Safe Whole Program Devirtualization Enablement
...des via > LD_PRELOAD, etc.) and I don't see how virtual functions are any different. > I think default LLVM behavior needs to be consistent for all > inter-procedural optimizations (be it inlining, devirtualization or > cloning). > > Maybe it's time to resurrect Hal's -fsemantic-interposition flag and use > it consistently throughout compiler? Users who need GCC-like semantics will > be able to employ this flag to prevent unsafe optimizations. > -fsemantic-interposition controls whether the compiler may assume that symbols are not interposed, and it has nothing...
2016 Nov 29
4
RFC: Add an "interposible" linkage type (and implement -fsemantic-interposition)
...the most-useful behavior > and we should keep the current behavior (at least as a default). I do > understand, however, that there are valid use cases for ELF interposition > and places where we should allow it (e.g. when compiling certain system > libraries). GCC recently added a flag -fsemantic-interposition/-fno-semantic-interposition, > where using -fno-semantic-interposition provides Clang/LLVM's behavior of > assuming that ELF interposition will not be used. > > It has been suggested that, to be self consistent, LLVM should emit global > symbols with protected ELF...
2016 Nov 30
2
RFC: Add an "interposible" linkage type (and implement -fsemantic-interposition)
...the most-useful behavior > and we should keep the current behavior (at least as a default). I do > understand, however, that there are valid use cases for ELF interposition > and places where we should allow it (e.g. when compiling certain system > libraries). GCC recently added a flag -fsemantic-interposition/-fno-semantic-interposition, > where using -fno-semantic-interposition provides Clang/LLVM's behavior of > assuming that ELF interposition will not be used. > > It has been suggested that, to be self consistent, LLVM should emit global > symbols with protected ELF...
2016 Mar 11
2
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...inked into the main executable. In this case, no interposition can occur because dynamic symbol search always starts in the executable. They also have -fno-semantic-interposition, which allows inlining strong definitions: > https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Optimize-Options.html#index-fsemantic-interposition-972 <https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Optimize-Options.html#index-fsemantic-interposition-972> Okay. The way we should be thinking about this is that -fno-semantic-interposition is the default rule on Clang. Now, if we fully embrace that by making symbols protec...
2016 Mar 11
4
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
> On Mar 11, 2016, at 8:33 AM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Mar 10, 2016 at 10:32 PM, John McCall via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > I mean, I’ve never really liked ELF’s stance on symbol interposition, but taking it as given, I’m not sure I agree that it’s reasonable to carve out virtual functions
2016 Feb 29
4
Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
----- Original Message ----- > From: "James Y Knight" <jyknight at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Monday, February 29, 2016 9:31:24 AM > Subject: Re: [llvm-dev] Possible soundness issue with
2019 Dec 17
1
RFC: Safe Whole Program Devirtualization Enablement
...much more aggressive devirtualization. Note that by default, unlike GCC, LLVM is liberal on visibility-constrained optimizations. In particular it freely performs inlining, IPA and cloning on them (see https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html which also suggested adding -fsemantic-interposition to actually respect visibility in optimizations). It's unclear why devirtualization should behave differently than other optimizations (at least by default). -I
2016 Mar 11
2
RFC: A new ABI for virtual calls, and a change to the virtual call representation in the IR
...>>> In summary, I think it is important that >>> >>> * a __attribute__((visibility("protected"))) maps to STV_PROTECED >>> * by default a decl with no attributes maps to STV_DEFAULT >> >> It’s not really my place to decide whether or not -fsemantic-interposition should be >> the default, so I’ll leave this up to others to debate. >> >> My instinct is that interposition is not actually important to very many people, >> and that the people who rely on it won’t really mind having to opt in. We have >> also been...
2016 Feb 29
0
Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")
On Feb 26, 2016 8:50 PM, "Hal Finkel" <hfinkel at anl.gov> wrote: > *From: *"James Y Knight via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Sanjoy Das" <sanjoy at playingwithpointers.com> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Thursday, February 25, 2016 1:41:43 PM > *Subject: *Re: [llvm-dev]
2019 Dec 11
5
RFC: Safe Whole Program Devirtualization Enablement
Please send any comments. As mentioned at the end I will follow up with some patches as soon as they are cleaned up and I create some test cases. RFC: Safe Whole Program Devirtualization Enablement =================================================== High Level Summary ------------------ The goal of the changes described in this RFC is to support aggressive Whole Program Devirtualization without