similar to: Build polly-amd64-linux Failure

Hi Tobias, could we use information about memory accesses of a SCoP statement and def-use chains to determine statements, which don’t contain matrix multiplication of the following form? for (int i = 0; i < Upper Bound1; i++) for (int j = 0; j < Upper Bound2; j++) for (int k = 0; k < Upper Bound3; j++) C[i][j] += A[i][k] * B[k][j] We could probably check that memory access

On 05/17/2016 01:47 PM, Michael Kruse wrote: > 2016-05-16 19:52 GMT+02:00 Roman Gareev <gareevroman at gmail.com>: >> Hi Tobias, >> >> could we use information about memory accesses of a SCoP statement and >> def-use chains to determine statements, which don’t contain matrix >> multiplication of the following form? > > Assuming s/don't/do you want

Hi, Recently I was looking at the potential of optimizing through Polly. The code that I am trying to optimize [1] adjusts a picture's colors to get an Instagram-like effect. To improve code analyzability on LLVM 3.9.0, I made the following changes: - Improve SCoP detection through -polly-process-unprofitable - Enable outer loop vectorization through -polly-vectorizer=stripmine, disabling

Hi all, I have summarized the top 10 compiler passes for Polly when compiling LLVM test-ssuite. Results can be viewed on: https://gist.github.com/tanstar/581bcea1e4e03498f935/raw/f6a4ec4e8565f7a7bbdb924cd59fcf145caac039/Polly-top10 Based on the comparison between "clang -O3" and "polly -O3" listed on:

On 08/08/2013 01:29 AM, Star Tan wrote: > Hi all, > > > I have summarized the top 10 compiler passes for Polly when compiling LLVM test-ssuite. Results can be viewed on: > https://gist.github.com/tanstar/581bcea1e4e03498f935/raw/f6a4ec4e8565f7a7bbdb924cd59fcf145caac039/Polly-top10 > > > Based on the comparison between "clang -O3" and "polly -O3"

The headers hadn't been regenerated in a long time, and there were a few minor divergences. Among other things, rnndb has changed naming to G80/etc, for now I've not tackled switching that over and manually replaced the nvidia codenames back to the chip ids. However no other modifications of the headergen'd headers was done. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>

These are copied directly from the mesa repository. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/hwdefs/gm107_texture.xml.h | 365 +++++++++++++++++ src/hwdefs/nvc0_3d.xml.h | 867 +++++++++++++++++++++++++---------------- 2 files changed, 892 insertions(+), 340 deletions(-) create mode 100644 src/hwdefs/gm107_texture.xml.h diff --git

Hi Johannes, Perfect, thanks! The CFG now looks very similar to what I got on LLVM 3.9.0 ([1] vs [2]). Any idea why setting -simplifycfg-sink-common=false is necessary? Similar to LLVM 5.0.1, the default for 3.9.0 is true [3], and setting it to false wasn't necessary in the latter version. [1] https://nautilus.bjornweb.nl/files/polly501-cfg-simplifycfg-sink-common.pdf [2]

Under certain circumstances, my compiler outputs basic blocks having the same function: bb_97: ; preds = %bb_1 %476 = getelementptr inbounds %LMtop.I0.ARType, %LMtop.I0.ARType* %0, i64 0, i32 6 %477 = bitcast i8** %476 to %LBstd.Cprocess.CRType** %478 = load %LBstd.Cprocess.CRType*, %LBstd.Cprocess.CRType** %477, align 8 %479 = getelementptr

Am Mi., 29. Mai 2019 um 13:31 Uhr schrieb Shawn Landden via llvm-dev <llvm-dev at lists.llvm.org>: > > On Wed, May 29, 2019 at 10:49 AM David Jones via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Under certain circumstances, my compiler outputs basic blocks having the same function: > > > > bb_97: ;

Hi Duncan & Tobi, Thanks a lot for your interest, and for pointing out differences in GIMPLE I missed. Attached is simplified test case. Is it good? Tobi, regarding runtime alias analysis: in KernelGen we already do it along with runtime values substitution. For example: <------------------ __kernelgen_main_loop_17: compile started ---------------------> Integer args substituted:

Fit NLE - was: [R] computer algebra in R Original post: https://stat.ethz.ch/pipermail/r-help/2023-November/478619.html Dear Kornad, I think I have started to understand what you try to achieve. The problem is to fit a NLE and compute the parameters of the NL-Eq. I have included the R Help-list back in the loop, as I am not an expert in optimization. Goal: y ~ I0 + IHD * hd + ID * d; where: y

Hi Steve, Thanks for the tip regarding MIOperandInfo, I didn't think of that part of the tablegen description. Sadly, I did actually mean: r1 = *(i0 += m0). So increment i0 by m0. Read memory the memory location "pointed" to by i0. Store in r1. Sadly I am not too familiar with compiler terminology, so I don't know if there is a proper term for such a load. On Thu, Oct 23,

Hi thank you for talking the time to help me with this. I have a sequence of numbers in a file and an equal sequence of various character, say(a b c d) each occurs more than once. I need to plot the numbers so that numbers corresponding to a in the other sequence would have green dots, those corresponding to b a red dot, nothing on c and blue square for d. i.e 2 a show a green dot 4 b show a

Sorry if this isn't the right place; but I'm facing an XCode 4 (LLVM 2.0 to Apple, I heard it's LLVM 2.9 under the hood) issue that may involve LLVM, and maybe some people on this list could help me short-circuit the source. I have a code pattern that, when used in XCode 4 in Objective C++ files, causes the whole IDE to go crash. It is a stripped sample to highlight the issue. In

From: "Richard W.M. Jones" <rjones at redhat.com> --- src/events.c | 25 +++++++++++++++++-------- 1 files changed, 17 insertions(+), 8 deletions(-) diff --git a/src/events.c b/src/events.c index f707e0b..9a1ca76 100644 --- a/src/events.c +++ b/src/events.c @@ -120,8 +120,7 @@ guestfs___call_callbacks_message (guestfs_h *g, uint64_t event, event == GUESTFS_EVENT_TRACE)

----- Original Message ----- > From: "Bruce Hoult" <bruce at hoult.org> > To: "Johnny Val" <johnnydval at gmail.com> > Cc: "<llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu> > Sent: Thursday, October 23, 2014 8:31:35 AM > Subject: Re: [LLVMdev] Question regarding getElementPtr/Addressing modes in backend > > Many CPU

Hi, I am writing a backend and having issues with properly lowering the result of getElementPtr ( specifically the add node that it generates). If we take this IR: %struct.rectangle = type { i24, i24 } ; Function Attrs: nounwind readonly define i24 @area(%struct.rectangle* nocapture readonly %r) #0 { entry: %width = getelementptr inbounds %struct.rectangle* %r, i16 0, i32 0 %0 = load i24*

This patch implements the drivers hooks needed for precise vblank timestamping. This is a complementary patch to Mario Kleiner's patches to to improve swap scheduling. With the complete patchset applied nouveau will be able to provide correct and precise pageflip timestamps (compliant to OML_sync_control spec) Kudos to Mario for his many helpful comments and testing. Signed-off-by: Lucas

2005/7/24, Chris Lattner <sabre at nondot.org>: > Ah, ok. In that case, you want to put all of the registers in one register > file, and not make the constant register allocatable (e.g. see > X86RegisterInfo.td, and note how the register classes include EBP and ESP, > but do not register allocate them (through the definition of > allocation_order_end()). > > -Chris