Eric Christopher
2014-Oct-31 01:46 UTC
[LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need
+1 to this. I'd slightly prefer a separate library (though moving the code vs not moving the code I'm relatively apathetic about), but just because I hate conditional compilation. -eric On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at apple.com> wrote:> I am mostly impartial to the two proposed solutions (separate library or > conditional compilation of the hooks into the tools). If we make it a > library I think we should make it a convenience library that is intended to > be used only with the tools and not an external supported library at all. > > -Juergen > > On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at apple.com> wrote: > > There is no real technical requirement for this. Currently we work around > the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and > carrying along the command line parsing code and ToolOutputFile isn’t > really a big drain. > > This seemed to me like the cleanest way to accomplish a goal of mine. The > goal I have is to be able to build an LLVM dylib and llc/opt/etc from the > same CMake invocation where the dylib does not have crash overrides and > signal handler hooks, but the tools do. > > There are other ways to accomplish this, but I felt that separating > libLLVMSupport into two libraries seemed the cleanest. An alternate > approach that could work for me would be to have the implementation of the > hooks only be compiled into the tools. > > -Chris > > On Oct 20, 2014, at 12:57 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > The question I have is -- does the actual source code need to move? I'm > wondering what aspects require a new library as opposed to different > sequence of things happening when initializing LLVM as a library vs. as a > tool. > > (We've definitely had trouble with the signal handlers ourselves, but I > thought we had solved it by using different code paths to set everything > else up...) > > On Mon, Oct 20, 2014 at 12:46 PM, Chris Bieneman <beanz at apple.com> wrote: > >> There are some pieces of functionality in LLVM today, that make sense for >> tools like llc, opt, clang, but they aren't relevant for embedded uses like >> LLVM in the JavaScript JIT. One example of this type of functionality is >> the signal handlers. >> >> I'd like to propose migrating content that is specifically designed for >> tools into a new ToolsSupport library. My initial candidates for the new >> library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any >> functionality specific to tools (i.e. ToolOutputFile and eventually command >> line parsing— once it can be factored out). >> >> The primary goal of this is to make it easy for uses of LLVM that aren't >> command line tools to not include functionality that isn't required for >> that use case. >> >> Thoughts? >> >> -Chris >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141031/a0173d49/attachment.html>
Chris Bieneman
2014-Oct-31 19:00 UTC
[LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need
Sounds like there is some interest here. I'll work up some patches with my preferred way to handle this, and we can shake things out from there. -Chris On Oct 30, 2014, at 6:46 PM, Eric Christopher <echristo at gmail.com> wrote:> +1 to this. > > I'd slightly prefer a separate library (though moving the code vs not moving the code I'm relatively apathetic about), but just because I hate conditional compilation. > > -eric > > On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at apple.com> wrote: > I am mostly impartial to the two proposed solutions (separate library or conditional compilation of the hooks into the tools). If we make it a library I think we should make it a convenience library that is intended to be used only with the tools and not an external supported library at all. > > -Juergen > >> On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at apple.com> wrote: >> >> There is no real technical requirement for this. Currently we work around the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and carrying along the command line parsing code and ToolOutputFile isn’t really a big drain. >> >> This seemed to me like the cleanest way to accomplish a goal of mine. The goal I have is to be able to build an LLVM dylib and llc/opt/etc from the same CMake invocation where the dylib does not have crash overrides and signal handler hooks, but the tools do. >> >> There are other ways to accomplish this, but I felt that separating libLLVMSupport into two libraries seemed the cleanest. An alternate approach that could work for me would be to have the implementation of the hooks only be compiled into the tools. >> >> -Chris >> >>> On Oct 20, 2014, at 12:57 PM, Chandler Carruth <chandlerc at google.com> wrote: >>> >>> The question I have is -- does the actual source code need to move? I'm wondering what aspects require a new library as opposed to different sequence of things happening when initializing LLVM as a library vs. as a tool. >>> >>> (We've definitely had trouble with the signal handlers ourselves, but I thought we had solved it by using different code paths to set everything else up...) >>> >>> On Mon, Oct 20, 2014 at 12:46 PM, Chris Bieneman <beanz at apple.com> wrote: >>> There are some pieces of functionality in LLVM today, that make sense for tools like llc, opt, clang, but they aren't relevant for embedded uses like LLVM in the JavaScript JIT. One example of this type of functionality is the signal handlers. >>> >>> I'd like to propose migrating content that is specifically designed for tools into a new ToolsSupport library. My initial candidates for the new library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any functionality specific to tools (i.e. ToolOutputFile and eventually command line parsing— once it can be factored out). >>> >>> The primary goal of this is to make it easy for uses of LLVM that aren't command line tools to not include functionality that isn't required for that use case. >>> >>> Thoughts? >>> >>> -Chris >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141031/844758e9/attachment.html>
Reid Kleckner
2014-Oct-31 20:46 UTC
[LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need
I'm in favor of splitting the code out into a new directory and using separate libraries if we're going to do this. Build systems should be really dumb, IMO. On Thu, Oct 30, 2014 at 6:46 PM, Eric Christopher <echristo at gmail.com> wrote:> +1 to this. > > I'd slightly prefer a separate library (though moving the code vs not > moving the code I'm relatively apathetic about), but just because I hate > conditional compilation. > > -eric > > On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at apple.com> > wrote: > >> I am mostly impartial to the two proposed solutions (separate library or >> conditional compilation of the hooks into the tools). If we make it a >> library I think we should make it a convenience library that is intended to >> be used only with the tools and not an external supported library at all. >> >> -Juergen >> >> On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at apple.com> wrote: >> >> There is no real technical requirement for this. Currently we work around >> the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and >> carrying along the command line parsing code and ToolOutputFile isn’t >> really a big drain. >> >> This seemed to me like the cleanest way to accomplish a goal of mine. The >> goal I have is to be able to build an LLVM dylib and llc/opt/etc from the >> same CMake invocation where the dylib does not have crash overrides and >> signal handler hooks, but the tools do. >> >> There are other ways to accomplish this, but I felt that separating >> libLLVMSupport into two libraries seemed the cleanest. An alternate >> approach that could work for me would be to have the implementation of the >> hooks only be compiled into the tools. >> >> -Chris >> >> On Oct 20, 2014, at 12:57 PM, Chandler Carruth <chandlerc at google.com> >> wrote: >> >> The question I have is -- does the actual source code need to move? I'm >> wondering what aspects require a new library as opposed to different >> sequence of things happening when initializing LLVM as a library vs. as a >> tool. >> >> (We've definitely had trouble with the signal handlers ourselves, but I >> thought we had solved it by using different code paths to set everything >> else up...) >> >> On Mon, Oct 20, 2014 at 12:46 PM, Chris Bieneman <beanz at apple.com> wrote: >> >>> There are some pieces of functionality in LLVM today, that make sense >>> for tools like llc, opt, clang, but they aren't relevant for embedded uses >>> like LLVM in the JavaScript JIT. One example of this type of functionality >>> is the signal handlers. >>> >>> I'd like to propose migrating content that is specifically designed for >>> tools into a new ToolsSupport library. My initial candidates for the new >>> library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any >>> functionality specific to tools (i.e. ToolOutputFile and eventually command >>> line parsing— once it can be factored out). >>> >>> The primary goal of this is to make it easy for uses of LLVM that aren't >>> command line tools to not include functionality that isn't required for >>> that use case. >>> >>> Thoughts? >>> >>> -Chris >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141031/67db777f/attachment.html>
Chris Bieneman
2014-Oct-31 21:07 UTC
[LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need
I was thinking of moving the files into a Tools subdirectory of Support, and having a new library generated from that. Does that mesh with what you’d like to see? I’ve gotten wrapped into a nasty internal bug hunt, so I probably won’t have patches until next week. I will also probably need to ask Eric for help with the autoconf side of things because my familiarity with autoconf ends at “run configure”. -Chris> On Oct 31, 2014, at 1:46 PM, Reid Kleckner <rnk at google.com> wrote: > > I'm in favor of splitting the code out into a new directory and using separate libraries if we're going to do this. > > Build systems should be really dumb, IMO. > > On Thu, Oct 30, 2014 at 6:46 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: > +1 to this. > > I'd slightly prefer a separate library (though moving the code vs not moving the code I'm relatively apathetic about), but just because I hate conditional compilation. > > -eric > > On Thu Oct 30 2014 at 5:55:59 PM Juergen Ributzka <juergen at apple.com <mailto:juergen at apple.com>> wrote: > I am mostly impartial to the two proposed solutions (separate library or conditional compilation of the hooks into the tools). If we make it a library I think we should make it a convenience library that is intended to be used only with the tools and not an external supported library at all. > > -Juergen > >> On Oct 20, 2014, at 1:02 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> >> There is no real technical requirement for this. Currently we work around the signal handlers by building with ENABLE_CRASH_OVERRIDES=NO, and carrying along the command line parsing code and ToolOutputFile isn’t really a big drain. >> >> This seemed to me like the cleanest way to accomplish a goal of mine. The goal I have is to be able to build an LLVM dylib and llc/opt/etc from the same CMake invocation where the dylib does not have crash overrides and signal handler hooks, but the tools do. >> >> There are other ways to accomplish this, but I felt that separating libLLVMSupport into two libraries seemed the cleanest. An alternate approach that could work for me would be to have the implementation of the hooks only be compiled into the tools. >> >> -Chris >> >>> On Oct 20, 2014, at 12:57 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: >>> >>> The question I have is -- does the actual source code need to move? I'm wondering what aspects require a new library as opposed to different sequence of things happening when initializing LLVM as a library vs. as a tool. >>> >>> (We've definitely had trouble with the signal handlers ourselves, but I thought we had solved it by using different code paths to set everything else up...) >>> >>> On Mon, Oct 20, 2014 at 12:46 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>> There are some pieces of functionality in LLVM today, that make sense for tools like llc, opt, clang, but they aren't relevant for embedded uses like LLVM in the JavaScript JIT. One example of this type of functionality is the signal handlers. >>> >>> I'd like to propose migrating content that is specifically designed for tools into a new ToolsSupport library. My initial candidates for the new library would be; anything guarded by ENABLE_CRASH_OVERRIDES, and any functionality specific to tools (i.e. ToolOutputFile and eventually command line parsing— once it can be factored out). >>> >>> The primary goal of this is to make it easy for uses of LLVM that aren't command line tools to not include functionality that isn't required for that use case. >>> >>> Thoughts? >>> >>> -Chris >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141031/d934748d/attachment.html>