search for: molle

On 2/2/19 1:39 AM, Luke Kenneth Casson Leighton wrote: > > > On Friday, February 1, 2019, Simon Moll <moll at cs.uni-saarland.de > <mailto:moll at cs.uni-saarland.de>> wrote: > > We could untie the mask length from the data length: > >   %result = call <scalable 4 x float> > @llvm.evl.fsub.v4f32(<scalable 4 x float> %x, <scalable 4

Hi, On 1/31/19 11:20 PM, Jacob Lifshay wrote: > We're in-progress designing a RISC-V extension > (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) > that would have variable-length vectors of short vectors (1 to 4): > <VL x <4 x float>> > where each predicate bit masks out a whole short vector. We're using > this extension

Howdy-ho I'm trying to launch explorer.exe to show a Windows desktop. I read somewhere that I should use some native DLLs, so my configuration is the default auto-generated .wine with some native DLLs on top: # cd # cd .wine/drive_c/windows # cp /mnt/windows/windows/explorer.exe . # cp /mnt/windows/windows/system32/{shlwapi,rpcrt4,ole32,oleaut32,shdocvw}.dll ./system/ # # wine explorer.exe

On Thu, Feb 7, 2019, 09:21 Simon Moll <moll at cs.uni-saarland.de> wrote: > > On 2/7/19 6:08 PM, David Greene wrote: > > Jacob Lifshay <programmerjake at gmail.com> writes: > > > >> So it would be handy for the vector length on evl intrinsics to be in > >> units of the mask length so we don't have to pattern match a division > >> in the

Hi, There is now an RFC for a roadmap to native vector predication support in LLVM and a prototype implementation:   https://reviews.llvm.org/D57504 The prototype demonstrates: -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy

Has any one had any success with cow implementation in xen ? I found this somewhere http://www.atconsultancy.nl/cowloop/, has anyone tried it out with xen ? -- regards, Anand _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

Hi Rusty, Would you be so kind and consider getting those two small fixes into 3.7 merge? All credits go to Brian, all shame on me :-) Cheers! Pawel Brian Foley (2): virtio_mmio: fix off by one error allocating queue virtio_mmio: Don't attempt to create empty virtqueues drivers/virtio/virtio_mmio.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) -- 1.7.9.5

Hi Rusty, Would you be so kind and consider getting those two small fixes into 3.7 merge? All credits go to Brian, all shame on me :-) Cheers! Pawel Brian Foley (2): virtio_mmio: fix off by one error allocating queue virtio_mmio: Don't attempt to create empty virtqueues drivers/virtio/virtio_mmio.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) -- 1.7.9.5

On 2/5/19 12:06 PM, Bruce Hoult wrote: > On Tue, Feb 5, 2019 at 1:23 AM Simon Moll <moll at cs.uni-saarland.de> wrote: >> I think this is the usual mixup of AVL and MVL. >> >> AVL: is part of the predicate and can change between vector operations >> just like a mask can (light weight). >> >> MVL: Is the physical vector register length and can be

Jacob Lifshay <programmerjake at gmail.com> writes: > So it would be handy for the vector length on evl intrinsics to be in > units of the mask length so we don't have to pattern match a division > in the backend. We could have 2 variants of the vector length > argument, one in terms of the data vector and one in terms of the mask > vector. we could legalize the mask

On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Simon Moll <moll at cs.uni-saarland.de> writes: > > > You are referring to the sub-vector sizes, if i am understanding > > correctly. I'd assume that the mask sub-vector length always has to be > > either 1 or the same as the data sub-vector length. For example,

Hi Simon, Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic

Invitation accepted, I am happy to help out with reviews, like I did with the previous VP patches. And of course agreed that things should be well defined, and that we shouldn't paint ourselves in a corner, but I don't think that this is the case. And it's not that I am in a rush, but I don't think this change needs to be predicated on a big change landing first like the LV

> You have similar problems with https://reviews.llvm.org/D79100 The new revision D79100<https://reviews.llvm.org/D79100> solves your comment 1), and I don't think your comments2) and 3) apply as there are no vendor specific intrinsics involved at all here. Just to quickly discuss the optimisation pipeline, D79100<https://reviews.llvm.org/D79100> is a small extension for the

@Xinmin, Saito: If Clang/the frontend generates the version there is no problem, or is there? The frontend knows about the original source type and it's ABI specific lowering already. @Francesco, we should even consider putting the generating capabilities outside of the OpenMP code generation (in the future). That could allow easier reuse by other frontends. Get Outlook for

On Mon, 2015-03-30 at 18:37 +0100, Michael S. Tsirkin wrote: > virtio_device_is_legacy_only is always false now, > drop the test from virtio mmio. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Slightly ironic ack ;-) after all the battle you fought for this: Acked-by: Pawel Moll <pawel.moll at arm.com> Thanks! Pawel

On Mon, 2015-03-30 at 18:37 +0100, Michael S. Tsirkin wrote: > virtio_device_is_legacy_only is always false now, > drop the test from virtio mmio. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Slightly ironic ack ;-) after all the battle you fought for this: Acked-by: Pawel Moll <pawel.moll at arm.com> Thanks! Pawel

Given that the xenvm machine is based on vexpress but with an extremely limited selection of peripherals (the guest is supposed to use virtual devices instead), add "xen,xenvm" to the list of compatible machines in mach-vexpress. Changes in v2: - remove include skeleton; - use #address-cells = <2> and #size-cells = <2>; - remove the debug bootargs; - use memory@80000000

On Mon, 4 Feb 2019 at 22:04, Simon Moll <moll at cs.uni-saarland.de> wrote: > On 2/4/19 9:18 PM, Robin Kruppe wrote: > > > > On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Simon Moll <moll at cs.uni-saarland.de> writes: >> >> > You are referring to the sub-vector sizes, if i am

Adam Nemet via llvm-dev <llvm-dev at lists.llvm.org> writes: > I spent some time chatting with Adam about this and have a better > understanding of his concerns here. It seems to me that if having > masking intrinsics is the long-term solution we want, we should do > that now (for add and sub) rather than building arbitrary matrix > layout info into