search for: ep_alwaysen

> Unfortunately, it looks like your email got garbled... Please attach patches > as actual files rather than as text at the end of the message, otherwise > lots of email software does the wrong thing with them... See attached. Sorry for that. -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.patch Type: text/x-patch Size: 1819 bytes Desc: not

...got garbled... Please attach patches >> as actual files rather than as text at the end of the message, otherwise >> lots of email software does the wrong thing with them... > See attached. Sorry for that. > <clang.patch> > + EP_EnabledOnOptLevel0 I'd rename this as EP_AlwaysEnabled - Devang > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> >> + EP_EnabledOnOptLevel0 > > I'd rename this as EP_AlwaysEnabled > Renamed, see the attachment. But note that one needs to add his pass at two extension points: at O0 and wherever else he wanted to add it. Won't such a name confuse the user? E.g. he may think that just adding a pass as "EP_AlwaysEnabled" should be enough to have it at any...

...inue the review process here? >> > > For future reference, please send patches which touch both LLVM and Clang > to llvm-commits and cfe-commits. However, looking at the Clang side of the > patch, it is totally fine. =D > Alex, Now, the patch is actually a bit confusing to me. EP_AlwaysEnabled should mean "works with O0 after inliner and with >= O1 somewhere late", but it doesn't look like it works this way (otherwise, you wouldn't need to call PMBuilder.addExtension twice). ? --kcc > > _______________________________________________ > LLVM Develope...

On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: >> >> Alex, >> Now, the patch is actually a bit confusing to me. >> EP_AlwaysEnabled should mean "works with O0 after inliner and with >= O1 >> somewhere late", but it doesn't look like it works this way (otherwise, you >> wouldn't need to call PMBuilder.addExtension twice). >> ? > This was actually my question to Devang. > Any othe...

> > Alex, > Now, the patch is actually a bit confusing to me. > EP_AlwaysEnabled should mean "works with O0 after inliner and with >= O1 > somewhere late", but it doesn't look like it works this way (otherwise, you > wouldn't need to call PMBuilder.addExtension twice). > ? This was actually my question to Devang. Any other suggestions for the...

...tch touches both llvm and clang) On Wed, Nov 30, 2011 at 9:33 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: > > >> > >> Alex, > >> Now, the patch is actually a bit confusing to me. > >> EP_AlwaysEnabled should mean "works with O0 after inliner and with >= O1 > >> somewhere late", but it doesn't look like it works this way (otherwise, > you > >> wouldn't need to call PMBuilder.addExtension twice). > >> ? > > This was actually my question...

...; On Wed, Nov 30, 2011 at 9:33 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: >> >> >> >> >> Alex, >> >> Now, the patch is actually a bit confusing to me. >> >> EP_AlwaysEnabled should mean "works with O0 after inliner and with >= >> O1 >> >> somewhere late", but it doesn't look like it works this way >> (otherwise, you >> >> wouldn't need to call PMBuilder.addExtension twice). >> >> ? >> >...

On Tue, Nov 29, 2011 at 8:56 AM, Alexander Potapenko <glider at google.com>wrote: > PS. Should we move the discussion to cfe-commits or it's ok to > continue the review process here? > For future reference, please send patches which touch both LLVM and Clang to llvm-commits and cfe-commits. However, looking at the Clang side of the patch, it is totally fine. =D --------------