search for: overhaul

On 13 February 2013 19:37, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is anyone currently working on overhauling the command-line processing code? > I'm currently doing some work on the CommandLine library but I don't think my work is going to help you. I'm current working on... - Allowing declared command line options to be put into categories to allow a categorised --help for tools - Pro...

Hello all, I am considering a major overhaul of the shuffle and boot functions in the Syslinux core. This means that the current API functions 0011h, 0012h, 001Ah and 001Bh will no longer be supported -- or, in fact, supportable. A new pair of functions will replace 001Ah and 001Bh; 0012h is redundant and 0011h will no longer be meaning...

For those interested in managing authorized_keys for multiple users, I''ve just overhauled my document here: https://reductivelabs.com/trac/puppet/wiki/Authorized_keysRecipe Best, Adam Kosmin windowsrefund on #puppet _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users

...Bill, > Problem > ======= > > LTO needs a way to pass options through to different parts of the compiler. In > particular, we need to pass code generation options to the back-end. The way we > want to do this is via the LLVM Attributes class. In order to do that, we need > to overhaul the Attributes class. > > The Attributes class right now isn't very extensible. After considering several > different options, we decided it was best to extend the Attributes class to > support *all* code generation options, even target-specific ones. It already > supports some o...

> attrgroup #1 = { "long-calls", "cpu=cortex-a8", "thumb" } > > define void @func() noinline ssp attrgroup(#1) { > ret void > } > I like the general idea. Just one clarification: In the above example, are the attributes taken from a list specified in the language ref (like current attributes) or can they be arbitrary "strings" (like

On 29 December 2012 21:21, Bill Wendling <wendling at apple.com> wrote: > Hi Rafael, > > Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. But then, what are the semantics that the middle end should use? Can a non thumb function be inlined in a

Hi Bill, On 30/12/12 03:21, Bill Wendling wrote: > Hi Rafael, > > Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. this sounds so much like metadata... What was the reason for not enhancing metadata to cover this use case? I'm sure you explained

I love it in principle. As you get closer to finalizing the syntax, etc. I might have some more detailed comments, but nothing really substantive. Minor API comment as that seems more immediate: On Wed, Sep 19, 2012 at 3:25 PM, Bill Wendling <wendling at apple.com> wrote: > An example syntax could be: > > // Building an Attribute > > Attributes A; > A.addAlignAttr(4)

I would like to add something to atttributes.h, attributes.cpp in the interim until your full scheme is available. A new attribute called "target" would be added to AttrKind. And target can take a list of strings. target("foo", "goo") For example. I would add a component targetAttrs to AttrBuilder Will this meet with resistance if I try and put this back? Reed

Overhauling Attributes Problem ======= LTO needs a way to pass options through to different parts of the compiler. In particular, we need to pass code generation options to the back-end. The way we want to do this is via the LLVM Attributes class. In order to do that, we need to overhaul the Attributes cl...

Reply to list as I had originally intended... ---------- Forwarded message ---------- From: Justin Holewinski <justin.holewinski at gmail.com> Date: Wed, Feb 13, 2013 at 4:23 PM Subject: Re: [LLVMdev] Overhauling the command-line processing/codegen options code To: Chris Lattner <clattner at apple.com> On Wed, Feb 13, 2013 at 3:53 PM, Chris Lattner <clattner at apple.com> wrote: > On Feb 13, 2013, at 11:37 AM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: >...

Looks like new attribute work is moving along quickly Maybe I should just wait. ??? On 01/11/2013 03:09 PM, Reed Kotler wrote: > I would like to add something to atttributes.h, attributes.cpp in the > interim until your full scheme is available. > > A new attribute called "target" would be added to AttrKind. > > And target can take a list of strings. > >

Hi Rafael, Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. -bw On Oct 4, 2012, at 7:47 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> attrgroup #1 = { "long-calls", "cpu=cortex-a8", "thumb" }

On Feb 13, 2013, at 2:32 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > > This is a very interesting one that is orthogonal to Bill's work. The preferred approach for this sort of thing is to change the LoopUnroll pass to take the unroll threshold as a constructor argument or a struct that wraps up all of the configuration settings. When the pass is *default*

The CRAN submission process seems in need of a massive overhaul. Why has this process not been automated yet? ? Patrick Perry Assistant Professor NYU Stern School of Business

I didn't seen any roadmap and plan about OrcJit & MCJIT. And would OrcJIT be stablize in version 7.0? Or latter version? Would MCJIT be removed in source tree, when? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

Is anyone currently working on overhauling the command-line processing code? We're currently having some design issues with this component, and I'd like to start a larger conversation on it. For context, I am talking from an "LLVM as a library" perspective instead of an "LLVM as a set of tools" perspective....

On Dec 31, 2012, at 4:37 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Bill, > > On 30/12/12 03:21, Bill Wendling wrote: >> Hi Rafael, >> >> Sorry, I forgot to respond to this. They can be arbitrary strings that are known only to the specific back-end. It may be beneficial to define them inside of the LangRef document though. > > this sounds so much

...e has implemented it yet. It > would be great to have this. I want to background process this for a bit, but it would be helpful to discuss some approaches first. There would appear to be three approaches: 1. Introduce a CC register class into the IR. This seems to be a fairly major overhaul. 2. Introduce a set of scalar and fp computation quasi-instructions that accept the same arguments as their computational counterparts, but produce *only* the condition code. For example: add i32 ... produces result add_cc i32 ... produces condition codes Once...

...k at ways to contribute to the project and stumbled upon "help with the main CentOS website rebuild effort". The WebsiteVer2 page [https://wiki.centos.org/WebsiteVer2] looks outdated though and I think the rebuild is complete, apart from the docs page. How is best to get involved with overhauling the docs section? And if relevant, can I please request a Wiki homepage for user OliverLeaver-Smith Many thanks, Oliver -- Oliver Leaver-Smith