search for: bikeshedding

Folks, On review http://reviews.llvm.org/D8197, we're basically down to two bikeshedding issues: 1. Title tags Some people use "[CSE] Change blah", others use "CSE: Change blah". I hadn't put anything regarding tags because not everyone use it and when they do, it's slightly different. I personally don't think it's a reason to argue about, so I'...

On 15 March 2015 at 15:06, Hal Finkel <hfinkel at anl.gov> wrote: > I used to use CSE:, but have now switched to using [CSE] because that seems to be the prevailing convention (and is somewhat more visually distinctive). I think it makes sense to codify that convention, but not to require them. Sometimes, there is nothing appropriate to use. Sometimes, the first or second word of the

On 15 March 2015 at 16:31, Hal Finkel <hfinkel at anl.gov> wrote: > I don't want to code when to use them. But it makes sense to say, "If you want to include a title tag, do it like this...". I'm ok with that. So, do we have consensus? 1. Don't require, but recommend using [] for tags. 2. Don't specify attribution more than just "patch by Foo." and

On 21 August 2017 at 11:53, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > One thing to be aware of with this is that (IIRC) tablegen uses the pattern to infer things about the pattern. One example I vaguely remember is that an empty pattern would result in the same effect as hasSideEffects=1 and I think there were others. Thanks for the note - excellent point. Looking at

On 15 March 2015 at 20:22, Chris Lattner <clattner at apple.com> wrote: > Can you post the entire revised diff that you want to include? Is it Diff 21913 on Phab? If so, LGTM. Hi Chris, Here's the final version: http://reviews.llvm.org/D8197 cheers, --renato

I agree with David's sentiment. The second method appears to be easier to follow. IMHO, this would be easier for external users that desire to modify the backend for their own custom extensions/instructions. On Fri, Aug 18, 2017 at 5:05 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 18 Aug 2017, at 10:55, Alex Bradbury <asb at asbradbury.org> wrote: >

...wever, I can’t omit bike-shedding :) > > Forgive me my directness, but current blog doesn’t look like something close to 2016. > > The blog already has lots of great articles. But it’s so hard to grasp valuable information when you have to read non-highlighted C++ code. Sorry for the bikeshedding, but the readability of the blog is also hampered considerably by re-posting all of the LLVM Weekly entries there. It’s already easy to subscribe to them at http://llvmweekly.org (which has its own RSS feed and is a great resource), but having copies of them make up 90% of the posts on blog.llvm.o...

As many of you know, I have a growing series of patches for a RISC-V backend under/awaiting review <https://reviews.llvm.org/differential/?authors=asb&order=updated>, <http://github.com/lowrisc/riscv-llvm>. I'll be posting a larger status update on that work either later today or tomorrow, this RFC focuses on an issue that came up during review which I think may benefit from

...tups - > >it's not yet clear why, but increasing buffer size > >back to what it was before helps. > > > >Fixes: d85b758f72b0 "virtio_net: fix support for small rings" > > Fixes: d85b758f72b0 ("virtio_net: fix support for small rings") I may be bikeshedding, but, personally I never do the parens--they're redundant given the quotes, and space is often tight. --b. > > >Reported-by: Mikulas Patocka <mpatocka at redhat.com> > >Reported-by: "J. Bruce Fields" <bfields at fieldses.org> > >Signed-off-by: Micha...

...tups - > >it's not yet clear why, but increasing buffer size > >back to what it was before helps. > > > >Fixes: d85b758f72b0 "virtio_net: fix support for small rings" > > Fixes: d85b758f72b0 ("virtio_net: fix support for small rings") I may be bikeshedding, but, personally I never do the parens--they're redundant given the quotes, and space is often tight. --b. > > >Reported-by: Mikulas Patocka <mpatocka at redhat.com> > >Reported-by: "J. Bruce Fields" <bfields at fieldses.org> > >Signed-off-by: Micha...

...}; is enough btw. I prefer to add the "," to make clear that we are initializing the entire struct, I read it as ", ...". > This should be backported to mesa 11.2 I guess, could you please send a v2 with this minor fix and add the cc thing? Sure, as soon as we're done bikeshedding on the "," :) Regards, Hans

...HW ops instead of directly. > Instead, each device implement the same interface, and then > vhost sits on top. Sure, but plugging in via ops/etc not via a bus and another struct device. > That bus is exactly what Greg KH proposed. There are other ways > to solve this I guess but this bikeshedding is getting tiring. This discussion was for a different goal, IMHO. > Come on it's an internal kernel interface, if we feel > it was a wrong direction to take we can change our minds later. > Main thing is getting UAPI right. This discussion started because the refcounting has been b...

...HW ops instead of directly. > Instead, each device implement the same interface, and then > vhost sits on top. Sure, but plugging in via ops/etc not via a bus and another struct device. > That bus is exactly what Greg KH proposed. There are other ways > to solve this I guess but this bikeshedding is getting tiring. This discussion was for a different goal, IMHO. > Come on it's an internal kernel interface, if we feel > it was a wrong direction to take we can change our minds later. > Main thing is getting UAPI right. This discussion started because the refcounting has been b...

...mit of 80 chars. And it hurts readability (at least my OCD) when style changes as you do with indent here. So my personal preference is to fix indent and accect longer lines. But you ask for a preferred style - which I do not think we have in this case. So it boils down to what you prefer. Enough bikeshedding, thanks for the quick response. Sam

...mit of 80 chars. And it hurts readability (at least my OCD) when style changes as you do with indent here. So my personal preference is to fix indent and accect longer lines. But you ask for a preferred style - which I do not think we have in this case. So it boils down to what you prefer. Enough bikeshedding, thanks for the quick response. Sam

Its awesome to see so much progress on this! A very minor question - why is it called M680x0 and not M68K given that's what the target arch/triple is and how its usually referred to? Sorry for the bikeshedding.... Simon. On 30/09/2020 21:14, Min-Yih Hsu via llvm-dev wrote: > Hi All, > > I've composed a draft roadmap for this new target. I've decided to try > Github's "Projects" feature, as it provides a clearer view to see all > the blockers and action items, IMAO...

...need a different driver option. Alternatives include >> 1) -fprofile-instrument=<...> -- this maps directly to the cc1 option we >> have today >> or >> 2) -fpgo-instr=<> -- suggested by Fred or >> 3) -fpgo-instr-method=<...> >> > > Random bikeshedding. I like fprofile-instrument because it merges a lot of > similar ideas behind instrumenting - and oddly enough what I was suggesting > in the x-ray thread before seeing this. > > +1 to -fprofile-instrument=... (as someone working on the XRay stuff, I'd much rather have less flags, a...

On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. > > I think there is a big benefit when these are all renamed to

On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. > > I think there is a big benefit when these are all renamed to

This probably qualifies as bikeshedding, but how strict are the style norms for TableGen? Some aspects of it, like individually and consecutively declaring all *_ENC variables in this manner: class ADDU_QB_ENC : ADDU_QB_FMT<0b00000>; To be used only once, in this manner: def ADDU_QB : ADDU_QB_ENC, ADDU_QB_DESC; Seem lik...