similar to: [LLVMdev] Optimization puzzle...

Here's a version that doesn't try to do block deletion on it's own. If you use -adce then -simplifycfg, you get what you want. It passes all tests except one, which is that we delete an invoke of a pure function, IE Transforms/ADCE/dce_pure_invoke.ll - I'm not sure why that's bad. The reason we delete it is because it returns false to I.mayHaveSideEffects(), and in particular,

On Fri, Dec 9, 2016 at 4:04 PM, James Y Knight <jyknight at google.com> wrote: > IMO, the LLVM function definitions should be a straightforward > transformation from the C function signatures, and clang should stop > mangling the function signatures with its own intimate knowledge of the > calling convention rules. > > Instead, clang could emit (still ABI-specific!)

Hi, I am working to improve SROA to generate better code when a method has a struct in its arguments. I would appreciate it if I could have any suggestions or comments on how I can best proceed with this optimization. * Problem * I observed that LLVM often generates redundant instructions around glibc’s istreambuf_iterator. The problem comes from the scalar replacement (SROA) for methods with an

> On Dec 6, 2017, at 02:28, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > > The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1. This sounds possibly problematic to me. The IR should be created with the correct address space to begin with. Changing this in the middle sounds suspect. > After this

#### I checked through every 3 factor * 3 loading case. #### While, 4 factor * 3 loading failed. #### the data is 6 factor * 3 loading require(sem); cor18<-read.moments(); 1 .68 1 .60 .58 1 .01 .10 .07 1 .12 .04 .06 .29 1 .06 .06 .01 .35 .24 1 .09 .13 .10 .05 .03 .07 1 .04 .08 .16 .10 .12 .06 .25 1 .06 .09 .02 .02 .09 .16 .29 .36 1 .23 .26 .19 .05 .04 .04 .08 .09 .09 1 .11 .13 .12 .03 .05 .03

> On Dec 5, 2017, at 13:53, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > >> On Dec 5, 2017, at 02:51, Haidl, Michael via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi dev list, >> >> I am currently exploring the integration of AMDGPU/ROCm into the PACXX project and observing some

On Fri, Dec 9, 2016 at 1:30 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 12/9/2016 8:45 AM, Reid Kleckner wrote: > > On Thu, Dec 8, 2016 at 5:37 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> So IIUC basically the *only* reason for this IR change is that we don’t >> want to pattern match in debug build? >> I don't

Is there some way to create a target-specific C-ABI compatible function signature using LLVM? For example, this C-Code:     typedef struct vpt_data {         char x;         int a;         char c;         float b;     } vpt_data;         void vpt_test( vpt_data vd ) { Generates a function:     define void @vpt_test(i64 %vd.coerce0, i64 %vd.coerce1) #0 { And also packs/unpacks the structure

Hello, I'm trying to change the default behavior for how structures are passed to functions to use pass-by-value. Currently LLVM's default behavior is to pass structures by reference. I'm not disputing the benefits of this but I really want to change the default behavior for experimentation purposes. To this end I've changed the code in DefaultABIInfo::classifyArgumentType() to

Hi, On Wed, Jun 13, 2012 at 9:55 AM, Martinez, Javier E < javier.e.martinez at intel.com> wrote: > Hello,**** > > ** ** > > I’m trying to change the default behavior for how structures are passed to > functions to use pass-by-value. Currently LLVM’s default behavior is to > pass structures by reference. I’m not disputing the benefits of this but I > really want to

Hi Dmitri, Regarding your first question, if you can use the MCJIT engine a caching mechanism will be available very soon. I'm preparing to commit a patch today to add this capability. I'm not sure what it would take to get something similar working with the older JIT engine. I expect it would take a fair amount of work because the older JIT engine isn't designed around object

Hi all, For my current project I need a couple of informations about JIT. I seen similar questions already, but the answers are a bit older and I hope somebody can provide me a recent information. 1. In my project I frequently construct LLVM IR, compile it and execute with JIT. Because the constructed IR is often the same (but can vary depending on input data) I would like to cache produced

Hello, I'm trying to apply the reg2mem pass on my bc file, but it somehow adds an instruction before a landingpad instruction and so I get a broken module error: The unwind destination does not have a landingpad instruction! %41 = invoke %class.x* @_ZN10xC2Ev(%class.x* %.reload19) to label %.noexc unwind label %88

Hi dev list, I am currently exploring the integration of AMDGPU/ROCm into the PACXX project and observing some strange behavior of the AMDGPU backend. The following IR is generated for a simple address space test that copies from global to shared memory and back to global after a barrier synchronization. Here is the IR is attached as as1.ll The output is as follows: 0 0 0 0 0 0 0 0 0 0 0 0 0

Hello, Are there any R functions available for performing a serial correlation test for short time series (e.g, series having between 10-14 observations)? Many thanks! Isabella R. Ghement, Ph.D. Ghement Statistical Consulting Company 301-7031 Blundell Road, Richmond, B.C., Canada, V6Y 1J5 Tel: 604-767-1250 Fax: 604-270-3922 E-mail: isabella at ghement.ca Web: www.ghement.ca -----Original

I did an update about 1/2 hr ago, and instead of failing to link with -O4, I'm getting an error elsewhere in the compile. I think I need to stop chasing the bleeding edge. pandora 142% svn update At revision 147455. pandora 143% uname -a Darwin pandora.psychiatry.uiowa.edu 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 pandora 144%

The poor interaction between exception handling and inlining in LLVM is one of the main motivations for the new exception handling models proposed recently. Here I give my analysis of the origin of the problem in the hope of clarifying the situation. Soon after dwarf exception handling was implemented in LLVM, I noticed that some programs would fail when compiled at -O3, for example the