search for: bikesheding

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'm in

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: >

On 18 May 2016, at 07:45, Alex Denisov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi everybody, > > I do write some Clang/LLVM related articles on my blog[1][2], and I will be happy to write for LLVM’s blog. > > However, I can’t omit bike-shedding :) > > Forgive me my directness, but current blog doesn’t look like something close to 2016. > > The

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

On Fri, Jun 02, 2017 at 12:34:57PM +0300, Sergei Shtylyov wrote: > Hello! > > On 6/2/2017 2:56 AM, Michael S. Tsirkin wrote: > > >commit d85b758f72b0 "virtio_net: fix support for small rings" > > Commit d85b758f72b0 ("virtio_net: fix support for small rings") > > >was supposed to increase the buffer size for small rings > >but had

On Fri, Jun 02, 2017 at 12:34:57PM +0300, Sergei Shtylyov wrote: > Hello! > > On 6/2/2017 2:56 AM, Michael S. Tsirkin wrote: > > >commit d85b758f72b0 "virtio_net: fix support for small rings" > > Commit d85b758f72b0 ("virtio_net: fix support for small rings") > > >was supposed to increase the buffer size for small rings > >but had

Hi, On 14-03-16 14:01, Samuel Pitoiset wrote: > > > On 03/14/2016 01:50 PM, Hans de Goede wrote: >> After pipe_grid_info.indirect was introduced, clover was not modified >> to set it causing it to pass uninitialized memory for it to launch_grid. >> >> This commit fixes this by zero-ing the entire pipe_grid_info struct when >> declaring it, to avoid similar

On Thu, Feb 13, 2020 at 10:41:06AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:05:42AM -0400, Jason Gunthorpe wrote: > > On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote: > > > > > > On 2020/2/13 ??9:41, Jason Gunthorpe wrote: > > > > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote: > > > > > > >

On Thu, Feb 13, 2020 at 10:41:06AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:05:42AM -0400, Jason Gunthorpe wrote: > > On Thu, Feb 13, 2020 at 10:58:44PM +0800, Jason Wang wrote: > > > > > > On 2020/2/13 ??9:41, Jason Gunthorpe wrote: > > > > On Thu, Feb 13, 2020 at 11:34:10AM +0800, Jason Wang wrote: > > > > > > >

Hi Thomas. > >> + > >> +/** > >> + * Returns the container of type &struct drm_gem_vram_object > >> + * for field bo. > >> + * @bo: the VRAM buffer object > >> + * Returns: The containing GEM VRAM object > >> + */ > >> +static inline struct drm_gem_vram_object* drm_gem_vram_of_bo( > >> + struct ttm_buffer_object

Hi Thomas. > >> + > >> +/** > >> + * Returns the container of type &struct drm_gem_vram_object > >> + * for field bo. > >> + * @bo: the VRAM buffer object > >> + * Returns: The containing GEM VRAM object > >> + */ > >> +static inline struct drm_gem_vram_object* drm_gem_vram_of_bo( > >> + struct ttm_buffer_object

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 >

On Fri, Jun 24, 2016 at 1:44 AM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> Sounds fine to me, though I am not a fan of using unstable in the option. >> I think a more meaningful way (that capture the essence of the

..."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 "drm_dev". > I have no strong preference here though, so "drmdev" or "drm" are fine > for me, too. Let the bikesheding begin! > > Some statistics: > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n > 1 struct drm_device *adev_to_drm > 1 struct drm_device *drm_ > 1 struct drm_device *drm_dev > 1 struct drm_device...

..."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 "drm_dev". > I have no strong preference here though, so "drmdev" or "drm" are fine > for me, too. Let the bikesheding begin! > > Some statistics: > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n > 1 struct drm_device *adev_to_drm > 1 struct drm_device *drm_ > 1 struct drm_device *drm_dev > 1 struct drm_device...

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 like avoidable clutter to me. The files tend to be pretty big,