----- Original Message -----> From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Yaron Keren" <yaron.keren at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" <arseny.kapoulkine at gmail.com> > Sent: Tuesday, January 26, 2016 9:39:34 AM > Subject: Re: [llvm-dev] lld: ELF/COFF main() interface > > On 26 January 2016 at 00:01, Yaron Keren via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > The context issue may be solved by making all functions and context > > data > > members of a class. Sort of having the convenience of global > > variables > > accessible from all linker functions but without the regular global > > variable > > problems of initializing and re-entry. so the class is suitable > > aspart of a > > library. Most clang and LLVM classes works this way, not passing > > contexts > > around. > > That is a way to solve the global variable problem. The bigger > problem > is the error handling. We can use a diagnostic handler instead of > calling exit, but we would still need to assume that the handler > doesn't return or we would get error_code spaghetti.I believe, however, that even when we want this functionality in a library, we don't want the implementation to be "error_code spaghetti." I propose that, for the purpose of treating lld as a library, we enable exception handling and use C++ exceptions. All of my users who use LLVM components as a library (for JIT, etc.) insist that I build LLVM with exceptions (and RTTI for that matter) enabled. For the purpose of creating a stand-alone lld build, we could certainly build with exceptions disabled if that yields a measurable performance difference. Thoughts? -Hal> > The main point is that the linker is still evolving. Case in point: > we > are experimenting on ways to change relocation application to better > handle possible optimizations and requirements of other ABIs. Had > this > already been exposed by a library interface such experiments would be > far harder. > > Postponing features is a pretty reasonable thing for a new project. > For example, we will probably implement -r, but right now there are > other features we want to get designed first. If someone figures out > how to make lld a library without a big cost, awesome, but it is not > the priority right now. > > Cheers, > Rafael > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Rafael Espíndola via llvm-dev
2016-Jan-26 17:25 UTC
[llvm-dev] lld: ELF/COFF main() interface
> I believe, however, that even when we want this functionality in a library, we don't want the implementation to be "error_code spaghetti."My opinion too. If some utility code is really useful, sure, we add error_code and move it to llvm, but I would like to avoid having all of lld look like that.> I propose that, for the purpose of treating lld as a library, we enable exception handling and use C++ exceptions. All of my users who use LLVM components as a library (for JIT, etc.) insist that I build LLVM with exceptions (and RTTI for that matter) enabled. For the purpose of creating a stand-alone lld build, we could certainly build with exceptions disabled if that yields a measurable performance difference. > > Thoughts?Something along those lines should work. We would probably still need a diag handler, but it would now *not* be fatal and 'error' would look like * call diag handler * if no exceptions, exit(1) * else, throw The reason being that it is a lot easier to print errors close to where they are found and we want to do it when exceptions are disabled too. Thanks, Rafael
I'd think it is probably better to discontinue this thread. I have a local patch to do what I can at this moment. I'll send it for review, so let's discuss on that review thread. On Tue, Jan 26, 2016 at 9:25 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote:> > I believe, however, that even when we want this functionality in a > library, we don't want the implementation to be "error_code spaghetti." > > My opinion too. If some utility code is really useful, sure, we add > error_code and move it to llvm, but I would like to avoid having all > of lld look like that. > > > I propose that, for the purpose of treating lld as a library, we enable > exception handling and use C++ exceptions. All of my users who use LLVM > components as a library (for JIT, etc.) insist that I build LLVM with > exceptions (and RTTI for that matter) enabled. For the purpose of creating > a stand-alone lld build, we could certainly build with exceptions disabled > if that yields a measurable performance difference. > > > > Thoughts? > > Something along those lines should work. We would probably still need > a diag handler, but it would now *not* be fatal and 'error' would look > like > > * call diag handler > * if no exceptions, exit(1) > * else, throw > > The reason being that it is a lot easier to print errors close to > where they are found and we want to do it when exceptions are disabled > too. > > Thanks, > Rafael > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/0beeaff6/attachment.html>
ChrisBieneman via llvm-dev
2016-Jan-26 17:35 UTC
[llvm-dev] lld: ELF/COFF main() interface
> On Jan 26, 2016, at 9:15 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> >> To: "Yaron Keren" <yaron.keren at gmail.com> >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" <arseny.kapoulkine at gmail.com> >> Sent: Tuesday, January 26, 2016 9:39:34 AM >> Subject: Re: [llvm-dev] lld: ELF/COFF main() interface >> >> On 26 January 2016 at 00:01, Yaron Keren via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> The context issue may be solved by making all functions and context >>> data >>> members of a class. Sort of having the convenience of global >>> variables >>> accessible from all linker functions but without the regular global >>> variable >>> problems of initializing and re-entry. so the class is suitable >>> aspart of a >>> library. Most clang and LLVM classes works this way, not passing >>> contexts >>> around. >> >> That is a way to solve the global variable problem. The bigger >> problem >> is the error handling. We can use a diagnostic handler instead of >> calling exit, but we would still need to assume that the handler >> doesn't return or we would get error_code spaghetti. > > I believe, however, that even when we want this functionality in a library, we don't want the implementation to be "error_code spaghetti." > > I propose that, for the purpose of treating lld as a library, we enable exception handling and use C++ exceptions. All of my users who use LLVM components as a library (for JIT, etc.) insist that I build LLVM with exceptions (and RTTI for that matter) enabled. For the purpose of creating a stand-alone lld build, we could certainly build with exceptions disabled if that yields a measurable performance difference. > > Thoughts?Using exceptions inside an LLVM project would be a significant deviation from the LLVM coding standards (http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions). Not saying we shouldn't do it (although I would strongly prefer if we didn't because exceptions make my skin crawl), but if we want to go down that path there should be a larger discussion about what it means to introduce exceptions. -Chris> > -Hal > >> >> The main point is that the linker is still evolving. Case in point: >> we >> are experimenting on ways to change relocation application to better >> handle possible optimizations and requirements of other ABIs. Had >> this >> already been exposed by a library interface such experiments would be >> far harder. >> >> Postponing features is a pretty reasonable thing for a new project. >> For example, we will probably implement -r, but right now there are >> other features we want to get designed first. If someone figures out >> how to make lld a library without a big cost, awesome, but it is not >> the priority right now. >> >> Cheers, >> Rafael >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Eric Christopher via llvm-dev
2016-Jan-26 17:44 UTC
[llvm-dev] lld: ELF/COFF main() interface
Very much agreed here. On Tue, Jan 26, 2016, 9:35 AM ChrisBieneman via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > > On Jan 26, 2016, at 9:15 AM, Hal Finkel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > ----- Original Message ----- > >> From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > >> To: "Yaron Keren" <yaron.keren at gmail.com> > >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" < > arseny.kapoulkine at gmail.com> > >> Sent: Tuesday, January 26, 2016 9:39:34 AM > >> Subject: Re: [llvm-dev] lld: ELF/COFF main() interface > >> > >> On 26 January 2016 at 00:01, Yaron Keren via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >>> The context issue may be solved by making all functions and context > >>> data > >>> members of a class. Sort of having the convenience of global > >>> variables > >>> accessible from all linker functions but without the regular global > >>> variable > >>> problems of initializing and re-entry. so the class is suitable > >>> aspart of a > >>> library. Most clang and LLVM classes works this way, not passing > >>> contexts > >>> around. > >> > >> That is a way to solve the global variable problem. The bigger > >> problem > >> is the error handling. We can use a diagnostic handler instead of > >> calling exit, but we would still need to assume that the handler > >> doesn't return or we would get error_code spaghetti. > > > > I believe, however, that even when we want this functionality in a > library, we don't want the implementation to be "error_code spaghetti." > > > > I propose that, for the purpose of treating lld as a library, we enable > exception handling and use C++ exceptions. All of my users who use LLVM > components as a library (for JIT, etc.) insist that I build LLVM with > exceptions (and RTTI for that matter) enabled. For the purpose of creating > a stand-alone lld build, we could certainly build with exceptions disabled > if that yields a measurable performance difference. > > > > Thoughts? > > Using exceptions inside an LLVM project would be a significant deviation > from the LLVM coding standards ( > http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions). > > Not saying we shouldn't do it (although I would strongly prefer if we > didn't because exceptions make my skin crawl), but if we want to go down > that path there should be a larger discussion about what it means to > introduce exceptions. > > -Chris > > > > > -Hal > > > >> > >> The main point is that the linker is still evolving. Case in point: > >> we > >> are experimenting on ways to change relocation application to better > >> handle possible optimizations and requirements of other ABIs. Had > >> this > >> already been exposed by a library interface such experiments would be > >> far harder. > >> > >> Postponing features is a pretty reasonable thing for a new project. > >> For example, we will probably implement -r, but right now there are > >> other features we want to get designed first. If someone figures out > >> how to make lld a library without a big cost, awesome, but it is not > >> the priority right now. > >> > >> Cheers, > >> Rafael > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/40ddcb33/attachment.html>
----- Original Message -----> From: "ChrisBieneman" <cbieneman at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Rafael Espíndola" <rafael.espindola at gmail.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" > <arseny.kapoulkine at gmail.com> > Sent: Tuesday, January 26, 2016 11:35:09 AM > Subject: Re: [llvm-dev] lld: ELF/COFF main() interface > > > > > On Jan 26, 2016, at 9:15 AM, Hal Finkel via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > > ----- Original Message ----- > >> From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > >> To: "Yaron Keren" <yaron.keren at gmail.com> > >> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" > >> <arseny.kapoulkine at gmail.com> > >> Sent: Tuesday, January 26, 2016 9:39:34 AM > >> Subject: Re: [llvm-dev] lld: ELF/COFF main() interface > >> > >> On 26 January 2016 at 00:01, Yaron Keren via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >>> The context issue may be solved by making all functions and > >>> context > >>> data > >>> members of a class. Sort of having the convenience of global > >>> variables > >>> accessible from all linker functions but without the regular > >>> global > >>> variable > >>> problems of initializing and re-entry. so the class is suitable > >>> aspart of a > >>> library. Most clang and LLVM classes works this way, not passing > >>> contexts > >>> around. > >> > >> That is a way to solve the global variable problem. The bigger > >> problem > >> is the error handling. We can use a diagnostic handler instead of > >> calling exit, but we would still need to assume that the handler > >> doesn't return or we would get error_code spaghetti. > > > > I believe, however, that even when we want this functionality in a > > library, we don't want the implementation to be "error_code > > spaghetti." > > > > I propose that, for the purpose of treating lld as a library, we > > enable exception handling and use C++ exceptions. All of my users > > who use LLVM components as a library (for JIT, etc.) insist that I > > build LLVM with exceptions (and RTTI for that matter) enabled. For > > the purpose of creating a stand-alone lld build, we could > > certainly build with exceptions disabled if that yields a > > measurable performance difference. > > > > Thoughts? > > Using exceptions inside an LLVM project would be a significant > deviation from the LLVM coding standards > (http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions).I'm well aware ;)> > Not saying we shouldn't do it (although I would strongly prefer if we > didn't because exceptions make my skin crawl), but if we want to go > down that path there should be a larger discussion about what it > means to introduce exceptions.Fair enough. To be honest, however, our error-handling story in LLVM is really pretty poor too, and some judicious use of exceptions could make things better. That having been said, having functions that might throw everywhere does harm the ability of the optimizer to do its work, and so I suspect we'll always want to support building with them disabled. You're correct, however, that we might want to make a higher-level decision about this (i.e. not in this thread). -Hal> > -Chris > > > > > -Hal > > > >> > >> The main point is that the linker is still evolving. Case in > >> point: > >> we > >> are experimenting on ways to change relocation application to > >> better > >> handle possible optimizations and requirements of other ABIs. Had > >> this > >> already been exposed by a library interface such experiments would > >> be > >> far harder. > >> > >> Postponing features is a pretty reasonable thing for a new > >> project. > >> For example, we will probably implement -r, but right now there > >> are > >> other features we want to get designed first. If someone figures > >> out > >> how to make lld a library without a big cost, awesome, but it is > >> not > >> the priority right now. > >> > >> Cheers, > >> Rafael > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
----- Original Message -----> From: "Rafael Espíndola" <rafael.espindola at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" <arseny.kapoulkine at gmail.com>, "Yaron Keren" > <yaron.keren at gmail.com> > Sent: Tuesday, January 26, 2016 11:25:11 AM > Subject: Re: [llvm-dev] lld: ELF/COFF main() interface > > > I believe, however, that even when we want this functionality in a > > library, we don't want the implementation to be "error_code > > spaghetti." > > My opinion too. If some utility code is really useful, sure, we add > error_code and move it to llvm, but I would like to avoid having all > of lld look like that. > > > I propose that, for the purpose of treating lld as a library, we > > enable exception handling and use C++ exceptions. All of my users > > who use LLVM components as a library (for JIT, etc.) insist that I > > build LLVM with exceptions (and RTTI for that matter) enabled. For > > the purpose of creating a stand-alone lld build, we could > > certainly build with exceptions disabled if that yields a > > measurable performance difference. > > > > Thoughts? > > Something along those lines should work. We would probably still need > a diag handler, but it would now *not* be fatal and 'error' would > look > like > > * call diag handler > * if no exceptions, exit(1) > * else, throw > > The reason being that it is a lot easier to print errors close to > where they are found and we want to do it when exceptions are > disabled > too.I agree. -Hal> > Thanks, > Rafael >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory