search for: upcasts

On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd at chromium.org> wrote: > > This change adds a new dma-buf operation that allows dma-bufs to be used > by virtio drivers to share exported objects. The new operation allows > the importing driver to query the exporting driver for the UUID which > identifies the underlying exported object. > > Signed-off-by: David

On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd at chromium.org> wrote: > > This change adds a new dma-buf operation that allows dma-bufs to be used > by virtio drivers to share exported objects. The new operation allows > the importing driver to query the exporting driver for the UUID which > identifies the underlying exported object. > > Signed-off-by: David

I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*

...ut almost all of the time they are upgraded to i32 because my add operations only happen on i32. So to be representative to my language definition, I have a lots of Sext/Zext and Truncs pretty much every time I add or subtract. As soon as I pass through InstCombine things look much nicer, all the upcasts and downcasts go away, but my test cases are simple. Is InstCombine pretty good about finding most/all such cases? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150417/04cee200/attachment.html>

Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: "Noralf Tr?nnes" <noralf at tronnes.org> Cc: Sam Ravnborg <sam

Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: "Noralf Tr?nnes" <noralf at tronnes.org> Cc: Sam Ravnborg <sam

...give > feedback on inaccuracies or suggested improvements for this document. These all look great, please apply. > One question regarding `classof()`s of the form: > static bool classof(const Foo *) { return true; } > Is the only purpose of this to optimize away "trivial" upcasts/isa<> > checks which are known statically? Yes. > If so, could we factor out this > case into Casting.h (using a trait like std::is_base_of<>)? That's a great idea, please do! :) -Chris

...ed PDF is the rendered version of this document. Please give feedback on inaccuracies or suggested improvements for this document. One question regarding `classof()`s of the form: static bool classof(const Foo *) { return true; } Is the only purpose of this to optimize away "trivial" upcasts/isa<> checks which are known statically? If so, could we factor out this case into Casting.h (using a trait like std::is_base_of<>)? --Sean Silva On Thu, Oct 4, 2012 at 2:06 AM, Chris Lattner <sabre at nondot.org> wrote: > It won't cause a negative effect, go for it! Dyn...

A question about the layout of structs: I decided to make my vtables out of structs rather than arrays. In other words, instead of being a table of opaque pointers, I decided to individually declare each entry with the correct type for that method. I figure that the various optimizers could do a better job if I preserve the type info. OK, so we come to the issue of inheritance: Suppose I have

...n page I think. > These all look great, please apply. Landed in r165290, r165291, r165292, r165293. >> One question regarding `classof()`s of the form: >> static bool classof(const Foo *) { return true; } >> Is the only purpose of this to optimize away "trivial" upcasts/isa<> >> checks which are known statically? > > Yes. > >> If so, could we factor out this >> case into Casting.h (using a trait like std::is_base_of<>)? > > That's a great idea, please do! :) Ok. We already have an is_base_of<> in Support/type...

...ress(sgt->sgl); I agree with Gerd, this looks pretty horrible to me. The usual way we've done these kind of special dma-bufs is: - They all get allocated at the same place, through some library or whatever. - You add a dma_buf_is_virtio(dma_buf) function, or maybe something that also upcasts or returns NULL, which checks for dma_buf->ops. - Once you've upcasted at runtime by checking for ->ops, you can add whatever fancy interfaces you want. Including a real&proper interface to get at whatever underlying id you need to for real buffer sharing between virtio devices...

...> > > The usual way we've done these kind of special dma-bufs is: > > > > - They all get allocated at the same place, through some library or > > whatever. > > > > - You add a dma_buf_is_virtio(dma_buf) function, or maybe something that > > also upcasts or returns NULL, which checks for dma_buf->ops. > > > > Thanks for a lot of valuable feedback and sorry for the late reply. > > While I agree that stuffing the resource ID in sg_dma_address() is > quite ugly (for example, the regular address arithmetic doesn't work), &...

...pecial dma-bufs is: > > > > > > > > - They all get allocated at the same place, through some library or > > > > whatever. > > > > > > > > - You add a dma_buf_is_virtio(dma_buf) function, or maybe something that > > > > also upcasts or returns NULL, which checks for dma_buf->ops. > > > > > > > > > > Thanks for a lot of valuable feedback and sorry for the late reply. > > > > > > While I agree that stuffing the resource ID in sg_dma_address() is > > > quite ugly (for ex...

...> > > > - They all get allocated at the same place, through some library or > > > > > > whatever. > > > > > > > > > > > > - You add a dma_buf_is_virtio(dma_buf) function, or maybe something that > > > > > > also upcasts or returns NULL, which checks for dma_buf->ops. > > > > > > > > > > > > > > > > Thanks for a lot of valuable feedback and sorry for the late reply. > > > > > > > > > > While I agree that stuffing the resource ID in sg_...

Hi Thomas, On Tuesday, 25 February 2020, Thomas Zimmermann <tzimmermann at suse.de> wrote: > Non-KMS drivers store state in struct drm_driver. This bloats the > structure for KMS drivers and prevents it from being declared with > 'static const' qualifiers. Moving the non-KMS state into a separate > data structure resolves this. > > Have you considered subclassing

Upcasting using a container_of macro is more typesafe, faster and easier for the compiler to optimize. Acked-by: Eric Anholt <eric at anholt.net> Acked-by: Sam Ravnborg <sam at ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: Daniel Vetter <daniel.vetter at

On Thu, May 14, 2020 at 11:08:52AM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 12:45 AM Daniel Vetter <daniel at ffwll.ch> wrote: > > On Wed, Mar 11, 2020 at 12:20 PM David Stevens <stevensd at chromium.org> wrote: > > > > > > This change adds a new dma-buf operation that allows dma-bufs to be used > > > by virtio drivers to share exported

Hi, > - for the runtime upcasting the usual approach is to check the ->ops > pointer. Which means that would need to be the same for all virtio > dma_bufs, which might get a bit awkward. But I'd really prefer we not > add allocator specific stuff like this to dma-buf. This is exactly the problem, it gets messy quickly, also when it comes to using the drm_prime.c helpers ...

Hello, I hope you can help me! I`m trying to tune svm parameters: cost and gamma for a landsat image classification, but I get an error and I can't understand it. I write this: > tune(svm, Class~., data = mdt01bis, ranges = list(gamma = 2^(-15:3), cost > = 2^(-5:15))) and R gives: Error en predict.svm(model, if (!is.null(validation.x)) validation.x else if (useFormula)

Am 03.04.20 um 15:58 schrieb Daniel Vetter: > Upcasting using a container_of macro is more typesafe, faster and > easier for the compiler to optimize. > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> > Cc: Dave Airlie <airlied at redhat.com> > Cc: Gerd Hoffmann <kraxel at redhat.com> > Cc: Daniel Vetter <daniel.vetter at ffwll.ch> > Cc: