similar to: [RFC] intrinsics for load/store-with-length semantics

Hi, this is an RFC for optional, named parameter tuples for intrinsics. The proposed syntax is: %z = call @llvm.some.intrinsic(%a, %b) optional_tuple(%x, %y, %z) where from the perspective of the call site %x, %y and %z are simply additional parameters. Optional parameter tuples would be very useful for constrained fp intrinsics and vector predication. Some examples: ; Default fpenv fadd

I agree that a single vector index is sufficient for many cases. Matt Pharr (from the ISPC compiler), showed me an interesting case where there is a single pointer into an array. In this case we need to have two indices, where the first index is zero. Once the basic patch is in, we can start looking at adding support for arrays and multiple indices. Nadav -----Original Message----- From: David

Hello, we’d like to propose the integration of a new backend into LLVM: NEC SX-Aurora TSUBASA Vector Engine (VE). We hope to get some feedback here and at EuroLLVM about the path and proper procedure of merging. The SX-Aurora VE is a Vector CPU on an PCI-E Accelerator card. It has 48GB memory from six HBM2 stacks, accessible with 1.2TB/s bandwidth, 8 cores with vector and scalar units, each.

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

Hi all, During the review of https://reviews.llvm.org/D65997 an issue was revealed, which relates to the decision of how compiler should represents constrained floating point operations. If a floating point operation requires rounding mode or exception behavior different from the default, it should be represented by constrained intrinsic (

Hello, today I updated a CentOS 7.6 ppc64le machine to CentOS 7.7. After reboot to the new kernel (4.18.0-80.7.2.el7.ppc64le) dkms could not build the nvidia-module. Error-message from dkms: Compiler version check failed: The major and minor number of the compiler used to compile the kernel: gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC) does not match the compiler used here: cc (GCC)

Hi Brian, > Thank you for this collection of patches. > > How can I test them? What platforms (computers) have the ppc64 or > POWER9 processor? The IBM Bounty Source page has a list of resources: https://www.bountysource.com/teams/ibm/bounties Travis also has ppc64le support, so if you add the linux-ppc64le target then FLAC will be tested on ppc64le. Thanks, Anton

Hi all, It's been a while since we've given an update on scalable vector support in LLVM. Over the last 12 months a lot of work has been done to make LLVM cope with scalable vectors. This effort is now starting to bear fruit with LLVM gaining more capabilities, including an intrinsics interface for AArch64 SVE/SVE2, LLVM IR Codegen for scalable vectors, and several loop-vectorization

> On 10/29/18 1:55 AM, Simon Matter wrote: >> To me it seems like, if they are smart, they will try to push IBM POWER >> and RedHat Linux together to establish real competition in the hardware >> market again (and of course don't forget to keep Fedora/CentOS alive)! > > Er, RHEL has been running on Power for a very long time. The fastest > supercomputer in the

Thanks. More below. > On Jul 3, 2019, at 12:06 PM, Justin Clift <justin at postgresql.org> wrote: > > Not sure personally, as I've not touched the libcxx source before. Looking > at line 876 for libcxx/include/chrono, gives this: > > https://github.com/llvm/llvm-project/blob/d2298e74235598f15594fe2c99bbac870a507c59/libcxx/include/chrono#L876

> On 8 Apr 2019, at 11:37, Simon Moll <moll at cs.uni-saarland.de> wrote: > > Hi, > > On 4/5/19 10:47 AM, Simon Pilgrim via llvm-dev wrote: >> On 05/04/2019 09:37, Simon Pilgrim via llvm-dev wrote: >>> On 04/04/2019 14:11, Sander De Smalen wrote: >>>> Proposed change: >>>> ---------------------------- >>>> In this RFC I

Thanks Florian. Tim you said: > Some cases can be undone by rematerialization, but not all, and it can involve a lot of effort which increases compile time. Do you have examples of cases where rematerialization is not possible? We are interested in learning about any previous attempts at trying to address the issue in RA. Have you tried it? Bardia Mahjour Compiler Optimizations IBM Toronto

Currently in the VM XML, I am passing the following command line argument as a passthrough argument: -netdev type=tap,id=net1,script=no,downscript=no,ifname=port3,vhost=on -device virtio-net-pci,netdev=net1,mac=00:00:00:00:00:01,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off Is there another way to represent this in the XML file? maybe that may solve the problem. On 24 July 2014

Hello again, I've been meaning to follow up on this thread for the last couple of weeks, my apologies for the delay. To summarise the feedback on the proposal for vector.reduce.fadd/fmul: There seems to be consensus to keep the explicit start value to better accommodate chained reductions (as opposed to generating IR that performs the reduction of the first element using extract/fadd/insert

I have my own llvm pass which requires mem2reg. It worked fine with opt. However, I was trying to make it work with clang as I needed it to run some spec cpu benchmarks. Is there any way that I can mention mem2reg (PromotePass) pass as a pre-requisite in my own pass's implementation? On Mon, Mar 21, 2016 at 9:01 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi, > > You

I have used the following command for my pass (without -mem2reg): clang -Xclang -load -Xclang MYPASS.so -c ../../tests/test1.c For mem2reg, I tried the following: clang -mllvm -mem2reg -Xclang -load -Xclang MYPASS.so -c ../../tests/test1.c On Mon, Mar 21, 2016 at 9:26 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Mar 21, 2016, at 6:23 PM, Syed Rafiul Hussain

fileUrl <- "https://data.baltimorecity.gov/api/views/dz54-2aru/rows.csv?accessType=DOWNLOAD"download.file(fileUrl,destfile="./data/Cameras.csv",method="curl") I tried it after installing package "RCurl" but it give error message: Error in download.file(fileUrl, destfile = "Cameras.csv") : unsupported URL schemeI can you help me to solve this

On Thu, Jul 24, 2014 at 03:48:06PM +0500, Asadullah Hussain wrote: > Let me clarify my question, I am using unmodified stock qemu (1.4.0) and > only the location of vhost file descriptor is different from default (I > don't remove the default /dev/vhost-net directory) > > The VHOST file descriptor is present in "/dev/vhost-0" directory instead of > the default

The following series adds initial vector support for PowerPC64. On POWER9, flac --best is about 3.3x faster. Amitay Isaacs (2): Add m4 macro to check for C __attribute__ features Check if compiler supports target attribute on ppc64 Anton Blanchard (5): configure.ac: Remove SPE detection code configure.ac: Add VSX enable/disable configure.ac: Fix FLAC__CPU_PPC on little endian, and add

I am using a custom qemu to launch a vhost enabled VM. The qemu doesn't use the default "/dev/vhost-net" directory as character device. Due to this I am getting the error: qemu-system-x86_64: -netdev type=tap,id=net1,script=no,downscript=no,ifname=port3,vhost=on: vhost-net requested but could not be initialized ​Is there a way to tell libvirt to ​avoid using the default