search for: interchangeably

> On Oct 1, 2020, at 20:45, Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > >> On Sep 27, 2020, at 12:52, Stefanos Baziotis via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi everyone, >> >> I was watching this video [1]. There's an example of an initialization loop for which >> Clang unfortunately

Hi, When I test "matmul" in the polly directory, I get the following performance data: //=============================== --> 12. Compare the runtime of the executables time ./matmul.normalopt.exe 0:23.53 real, 23.48 user, 0.00 sys time ./matmul.polly.interchanged.exe 0:22.86 real, 22.82 user, 0.01 sys time ./matmul.polly.interchanged+tiled.exe 0:22.87 real, 22.83 user, 0.00 sys

Hello, I've been playing around with the really simple example of not cache friendly loop like this: #define N 100 void foo(int** __restrict__ a, int** __restrict__ b) { for (int i = 0; i < N; ++i) for (int j = 0; j < N; ++j) a[j][i] += b[j][i]; } link to compiler explorer:

Are IVR and "Auto Attendant" interchangeable terms? They both do the "Press 1 for" thing. Sales is asking me how to word it and I've always used both terms interchangeably.

unsigned int and FLAC__uint32 are used interchangeably, leading to warnings with platforms (e.g. djgpp) where int32_t is long: bitreader.c: In function `FLAC__bitreader_read_rice_signed': bitreader.c:721: warning: passing arg 2 of `FLAC__bitreader_read_unary_unsigned' from incompatible pointer type bitreader.c: In function `FLAC__bitreader_rea...

On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> warnings with platforms (e.g. djgpp) where int32_t is long: > > Is `sizeof int == 4` though? Yes, obviously it is > I couldn't image FLAC working correctly > if it wasn't. > > Erik

Hi Tobias, I think that we could split a patch that contains an implementation of tiling, interchanging and unrolling of specific loops into three separate patches: 1. The first one adds a class that describes a processor model. It also adds a new command line parameter that contains all necessary parameters of a target architecture, which are used to construct objects of the class. 2. The

On Wed, Jun 8, 2016 at 10:20 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > ------------------------------ > > *From: *"Vikram TV via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"DEV" <llvm-dev at lists.llvm.org> > *Sent: *Wednesday, June 8, 2016 2:58:17 AM > *Subject: *[llvm-dev] [Proposal][RFC] Cache aware Loop Cost Analysis >

On Thu, Jun 23, 2016 at 9:54 AM, Adam Nemet <anemet at apple.com> wrote: > > On Jun 9, 2016, at 9:21 AM, Vikram TV via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Wed, Jun 8, 2016 at 10:20 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> ------------------------------ >> >> *From: *"Vikram TV via

Hi Roman, On Tue, May 31, 2016 at 9:57 AM, Roman Gareev <gareevroman at gmail.com> wrote: > Hi Tobias, > > I think that we could split a patch that contains an implementation of > tiling, interchanging and unrolling of specific loops into three > separate patches: > > 1. The first one adds a class that describes a processor model. It > also adds a new command line

On Thu, Jun 23, 2016 at 11:34 PM, Adam Nemet <anemet at apple.com> wrote: > > > >> Hi Vikram, >> >> Is the analysis result specific to a loop nest or to a loop nest together >> with a set of reference groups? >> > The result is specific to each loop in the loop nest and the calculations > are based on the references in the loop nest. > >

With primitive types, I can interchange literal usage and type aliases in IR: %mytype = type i32 define void @foo(%mytype* %ptr) { %t1 = load *%mytype** %ptr store i32 *%t1*, *i32** %ptr ret void } But for structs, I cannot: %mytype = type { i32, i32 } define void @foo(%mytype* %ptr) { %t1 = load *%mytype** %ptr store* { i32, i32 }* %t1, *{ i32, i32 }** %ptr ret void }

Justin, http://llvm.org/docs/LangRef.html#structure-type "Identified types can be recursive, can be opaqued, and are never uniqued." Do you think it would be less descriptive? "Identified type, aka named llvm::StructType, is never uniqued against other identified types nor literal types, aka unnamed StructType(s)." ? See also;

Ozkan Sezer wrote: > > Ozkan Sezer wrote: > > > >> unsigned int and FLAC__uint32 are used interchangeably, leading to > >> warnings with platforms (e.g. djgpp) where int32_t is long: > > > > Is `sizeof int == 4` though? > > Yes, obviously it is Well I've just pushed a patch that purges the code base of `unsigned`. Please test and let us know how it goes. Erik -- -----...

Suppose x and y are numeric vectors of the same length. plot(x,y) #scatterplot lmObj1 <- lm(y~x) # best fit line abline(lmObj1) # good lmObj2 <- lm(x~y) #get best fit but with axes interchanged abline(lmObj2) # not what I want. I want the correct line, drawn on the same graph, but with # response and predictor variables interchanged One way to proceed would be to

On 1/14/17, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Ozkan Sezer wrote: > >> > Ozkan Sezer wrote: >> > >> >> unsigned int and FLAC__uint32 are used interchangeably, leading to >> >> warnings with platforms (e.g. djgpp) where int32_t is long: >> > >> > Is `sizeof int == 4` though? >> >> Yes, obviously it is > > Well I've just pushed a patch that purges the code base of `unsigned`. > Please test and let us...

Hi, This is a proposal about implementing an analysis that calculates loop cost based on cache data. The primary motivation for implementing this is to write profitability measures for cache related optimizations like interchange, fusion, fission, pre-fetching and others. I have implemented a prototypical version at http://reviews.llvm.org/D21124. The patch basically creates groups of references

Hello All... I gave a task to my students that involved using mclust to look for clusters in some bivariate data of isotopes vs various mining locations. They discovered something I didn?t expect; the data (called tur) is appended below. p <- qplot(x = dD, y = dCu65, data = tur, color = mine) print(p) # simple bivariate plot of the data; looks fine mod1 <- Mclust(tur[,2:3]) mod1$G mod2

lvqcl wrote: > Is it Ok to pass FLAC__int32* in a function that expects int* ? Well FLAC__int32 is just a 32 bit integer and on all the platforms/ architecures/compilers that FLAC supports FLAC__int32 and int are the same. As for pointers, all pointers are the same until you try an increment them. If you have some type, lets call it sometype_t, and a pointer to types of sometype_t :

Erik de Castro Lopo wrote: > Well FLAC__int32 is just a 32 bit integer and on all the platforms/ > architecures/compilers that FLAC supports FLAC__int32 and int are > the same. > > Personally I think the FLAC__xxxx stuff should go, to be replaced with > C standard int32_t, uint32_t, int16_t etc, at least for internal code. > I am slowly doing that when I touch code. > >