Displaying 5 results from an estimated 5 matches for "namespacification".
Did you mean:
namespac'ification
2013 Sep 18
0
[LLVMdev] [RFC] Internal command line options should not be statically initialized.
...se to me, and having tool options use toolopt<> (or something) also makes perfect sense.
If you're going to go and tackle pass-specific options, I think that we should consider changing the syntax and overall design of the command line options. We already have some manual name mangling/namespacification of options (e.g. -tail-dup-limit=). Perhaps we should formalize this somehow?
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130918/9f083950/attachment.html>
2013 Sep 17
3
[LLVMdev] [RFC] Internal command line options should not be statically initialized.
On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote:
> Wait, I have a terrible idea. Why don't we roll our own .init_array style
> appending section? I think we can make this work for all toolchains we
> support.
>
Andy and I talked about this, but I don't think its worth it. My opinion is:
1. For tool options (the top-level llc, opt, llvm-as
2013 Sep 19
3
[LLVMdev] [RFC] Internal command line options should not be statically initialized.
...and having tool options use toolopt<> (or something) also makes perfect sense.
>
> If you're going to go and tackle pass-specific options, I think that we should consider changing the syntax and overall design of the command line options. We already have some manual name mangling/namespacification of options (e.g. -tail-dup-limit=). Perhaps we should formalize this somehow?
Obviously, based on the 18 responses I've gotten, the tone of my first email was misleading.
I don’t want to stifle discussion, but to be clear, the only thing I propose to tackle immediately is the removal of stati...
2013 Sep 19
0
[LLVMdev] [RFC] Internal command line options should not be statically initialized.
...l options use toolopt<> (or something) also makes perfect
> sense.
>
> If you're going to go and tackle pass-specific options, I think that we
> should consider changing the syntax and overall design of the command line
> options. We already have some manual name mangling/namespacification of
> options (e.g. -tail-dup-limit=). Perhaps we should formalize this somehow?
>
>
> Obviously, based on the 18 responses I've gotten, the tone of my first
> email was misleading.
>
> I don’t want to stifle discussion, but to be clear, the only thing I
> propose to tack...
2003 Nov 18
0
LLVM Status Update
...VM interpreter work. In
particular, he implemented exception handling and variable argument
handling support.
5. Bugpoint no longer crashes while performing "final cleanups". This
allowed removing the -disable-final-cleanups option (yaay).
6. Reid Spencer contributed the LLVM Namespacification patch, which
allows LLVM to interoperate with other people's source bases better:
http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-November/000554.html
7. Misha is on a quest to clean up our web pages, and make them really be
HTML 4.0 compliant. In the process he's converting the...