similar to: [LLVMdev] RFC: generation of PSAD instruction

On Wed, Jan 28, 2015 at 7:50 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi Vijender, > > Thanks for posting this, there is wide support here for improving our support for reductions of various kinds, both in flavor and robustness. I've cc'd some others who have previously discussed this. > > James has advocated in the past for an intrinsic for horizontal reductions,

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Dibyendu Das" <Dibyendu.Das at amd.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 4, 2014 5:23:30 AM > Subject: Re: [LLVMdev] supporting SAD in loop vectorizer > > On 4 November 2014 11:06, Das, Dibyendu <Dibyendu.Das at amd.com> wrote:

----- Original Message ----- > From: "Dibyendu Das" <Dibyendu.Das at amd.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Renato Golin" <renato.golin at linaro.org> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 4, 2014 12:15:12 PM > Subject: RE: [LLVMdev] supporting SAD in loop vectorizer > > Here's the simple SAD

----- Original Message ----- > From: "James Molloy" <james at jamesmolloy.co.uk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Dibyendu Das" <Dibyendu.Das at amd.com>, llvmdev at cs.uiuc.edu > Sent: Tuesday, November 11, 2014 8:21:37 AM > Subject: Re: [LLVMdev] supporting SAD in loop vectorizer > > > If you'd like to

On Oct 26, 2011, at 1:18 PM, Nicolas Capens wrote: > On 24/10/2011 9:50 PM, Bill Wendling wrote: >> On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: >> >>> Hi all, >>> >>> I'm working on a graphics project which uses LLVM for dynamic code >>> generation, and I noticed a major performance regression when upgrading >>> from LLVM

Hi Bill, Comments inline: On 24/10/2011 9:50 PM, Bill Wendling wrote: > On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: > >> Hi all, >> >> I'm working on a graphics project which uses LLVM for dynamic code >> generation, and I noticed a major performance regression when upgrading >> from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I

Hi, I am new to speex library. I am doing project in VC++. My project details are, I have to capture voice from mic and encode it then decode and play. I am capturing the voice and storing in a buffer from there i am reading frame by frame ( 160 bytes) . These bytes i am converting to short int then calling speex_encode-int(). The output buffer i am passing to doder speex_decode_int() function.

Hi, I''d like to use psad from www.cipherdyne.com that analyze iptables log messages on my firewall-shorewall. It complains to incorrectly configured iptables when starting. This is the message : -------------------------------------------------------------------------------------------------- ** The INPUT chain in the iptables ruleset on debian4 includes a default LOG rule for all

Just installed psad and am testing it. This morning I awoke to an email saying: [-] You may just need to add a default logging rule to the /sbin/ip6tables ''filter'' ''INPUT'' chain on hydra. For more information, see the file "FW_HELP" in the psad sources directory or visit: http://www.cipherdyne.org/psad/docs/fwconfig.html Well I have

> On Fri, 2003-09-19 at 07:10, Tom Eastep wrote: > > On Fri, 2003-09-19 at 06:59, Tom Eastep wrote: > > > On Fri, 2003-09-19 at 06:52, Petr Novák wrote: > > > > > > > Is there a way for shorewall to be comatible with psad ? > > > > > > >From the above messages, it doesn''t seem likely. > > > > > > >

Hi I'm trying to print several plots to a multi-page postscript file. Some plots are output of basic commands, some are produced by "trellis" commands (from the package lattice). Right now I'm not able to get a straightforward black and white color scheme for the latter kind: when I open the postscript file the "trellis" plots are invisible, or parts of them are

On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: > Hi all, > > I'm working on a graphics project which uses LLVM for dynamic code > generation, and I noticed a major performance regression when upgrading > from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it > entirely). > > I found out that the performance regression is due to removing

Hi, Tank you for your reply. I have tried the sample programs given the manual and done encoding and decoding a wave file. That is working fine. I have already read the manual and API reference. But this problem did not occured with the wave file encoding/decoding. While capturing the data from MIC and encoding/decoding is giving this problem. Thanks and Regards, Vijender Reddy, -----

Hi all, I'm working on a graphics project which uses LLVM for dynamic code generation, and I noticed a major performance regression when upgrading from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it entirely). I found out that the performance regression is due to removing support for lowering 64-bit vector operations to MMX, and using SSE2 instead. My code uses a

The following function compiles with -O3 into the following IR. http://llvm.org/docs/Passes.html#simplifycfg-simplify-the-cfg says - Eliminates a basic block that only contains an unconditional branch. but the first and third blocks in the compiled function only contain an unconditional branch; I would have expected them to be eliminated. What am I missing? double f(double *a) { for (int i

"Finkel, Hal J." <hfinkel at anl.gov> writes: > I think that it's really important that we're specific about the goals > here. Exactly what kinds of optimizations are we aiming to (more-easily) > enable? There certainly exists hardware with instructions that help > vectorize complex multiplication, for example, and having a builtin > complex type would

In the RISC-V V extension, there is no upper limit to the size vector registers can be in a future CPU. (Formally, the upper limit is at least 2^31 bytes) Generic code can enquire the size, dynamically allocate space, and transparently save and restore the contents of a vector register or registers. On Fri, May 24, 2019 at 11:28 AM JinGu Kang via llvm-dev <llvm-dev at lists.llvm.org>

Hi, Are there any objections to going ahead with this? If not, we'll try to get the patches reviewed and committed after the 7.0 branch occurs. -Graham > On 2 Jul 2018, at 10:53, Graham Hunter <Graham.Hunter at arm.com> wrote: > > Hi, > > I've updated the RFC slightly based on the discussion within the thread, reposted below. Let me know if I've missed

JinGu: I’m not Graham, but you might find the following link a good starting point. https://community.arm.com/developer/tools-software/hpc/b/hpc-blog/posts/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture The question you ask doesn’t have a short answer. The compiler and the instruction set design work together to allow programs to be compiled without knowing

Hi, Now that Sander has committed enough MC support for SVE, here's an updated RFC for variable length vector support with a set of 14 patches (listed at the end) to demonstrate code generation for SVE using the extensions proposed in the RFC. I have some ideas about how to support RISC-V's upcoming extension alongside SVE; I'll send an email with some additional comments on