similar to: Aggregate load/stores

I understand these objections. They ends up being a problem at the limit (ie the example of the 64k store or 1Mb+ aggregate). These probably require their own fix or probably just shouldn't be supported. That being said, there is a vast space between what is done now and aggregate so big that it causes real hard problems like the ones you mention. reducing that gap seems like a win to me.

2015-08-17 11:26 GMT-07:00 Mehdi Amini <mehdi.amini at apple.com>: > Hi, > > On Aug 17, 2015, at 12:13 AM, deadal nix via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 2015-08-16 23:21 GMT-07:00 David Majnemer <david.majnemer at gmail.com>: > >> >> >> Because a solution which doesn't generalize is not a very powerful

I've definitely "run into this problem", and I would very much love to remove my kludges [that are incomplete, because I keep finding places where I need to modify the code-gen to "fix" the same problem - this is probably par for the course from a complete amateur compiler writer and someone that has only spent the last 14 months working (as a hobby) with LLVM]. So whilst

2015-08-16 23:21 GMT-07:00 David Majnemer <david.majnemer at gmail.com>: > > > Because a solution which doesn't generalize is not a very powerful > solution. What happens when somebody says that they want to use atomics + > large aggregate loads and stores? Give them yet another, different answer? > That would mean our earlier, less general answer, approach was either

Even if I turn to -O0 [in other words, no optimisation passes at all], it takes the same amount of time. The time is spent in 12.94% lacsap lacsap [.] llvm::SDNode::use_iterator::operator== 7.68% lacsap lacsap [.] llvm::SDNode::use_iterator::operator* 7.53% lacsap lacsap [.] llvm::SelectionDAG::ReplaceAllUsesOfValueWith 7.28% lacsap

2015-08-16 22:10 GMT-07:00 David Majnemer <david.majnemer at gmail.com>: > > > I would argue that a fix in the wrong direction is worse than the status > quo. > How is proposed change worse than status quo ? > > >> >> The argument that target are relying on InstCombine to mitigate IR >> requiring legalization seems dubious to me. First, because both

It is pretty clear people need this. Let's get this moving. I'll try to sum up the point that have been made and I'll try to address them carefully. 1/ There is no good solution for large aggregates. That is true. However, I don't think this is a reason to not address smaller aggregates, as they appear to be needed. Realistically, the proportion of aggregates that are very large

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "deadal nix" <deadalnix at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, August 19, 2015 7:24:28 PM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan > > Hi, > > To be sure,

----- Original Message ----- > From: "deadal nix" <deadalnix at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, August 21, 2015 1:24:04 AM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan >

----- Original Message ----- > From: "deadal nix" <deadalnix at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, August 20, 2015 4:09:17 PM > Subject: Re: [llvm-dev] [RFC] Aggreate load/store, proposed plan >

Hi all, One area where LLVM suck pretty badly is aggregate store and loads. clang do not use them so there are not seen as important, and aren't handled nicely. Other frontends work around the issue as it is not handled properly and we ends up with some kind of chicken and egg issue. I recently proposed a diff to be able to optimize load from aggregate stores in GVN without great success.

deadal nix via llvm-dev wrote on Mon, 17 Aug 2015: > OK, what about that plan : > > Slice the aggregate into a serie of valid loads/stores for non atomic ones. > Use big scalar for atomic/volatile ones. > Try to generate memcpy or memmove when possible ? Are memcpy/memmove guaranteed to be handled inline, i.e., without a call to libc? Or are there plans to do this in the context

Hi, To pretty print aggregates by various dimensions I needed to add a empty row in output of aggregate. For example. d<-(aggregate(data[,cbind("x")], by=list(data$group1,data$group2), sum)) Group.1 Group.2 x 1 A N 3 2 A Y 2 3 B N 420164905 Is there a way to add an empty

Hi, I have a ts object with a frequency of 4, i.e., quarterly data, and I would like to calculate the mean for each quarter. So for example: > ts.data=ts(1:20,start=c(1984,2),frequency=4) > ts.data Qtr1 Qtr2 Qtr3 Qtr4 1984 1 2 3 1985 4 5 6 7 1986 8 9 10 11 1987 12 13 14 15 1988 16 17 18 19 1989 20 If I do this manually, the mean

Dear Lest, I have a two-variable data frame as follows (the time peirod of the actual data set is 10 years): Date Amount 1 6/1/2007 1 2 6/1/2007 1 3 6/4/2007 2 4 6/5/2007 2 5 6/11/2007 3 6 6/12/2007 3 7 6/12/2007 3 8 6/13/2007 3 9 6/13/2007 3 10 6/18/2007 4 11 6/18/2007 4 12 6/25/2007 5 13 6/28/2007 5

I opened a bug report earlier today but it doesn''t seem to have been added to the bugs database. I''m posting here in case one of the Crossbow developers might see it and confirm this behavior. Description Duplicate packets are generated whenever an aggregate is introduced into the network configuration. We''ve ruled out switch ports and physical bge interfaces as

Hi All, I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy intrinsic. When set to '1' (the auto-upgrade default), this argument would indicate that the source and destination arguments may perfectly alias (otherwise they must not alias at all - memcpy prohibits partial overlap). While the C

Hello Alexander, > Interesting topic. Is any such optimization reachable from C? Yes, I think so - both PassBuilder and PassManagerBuilder add MemCpyOpt & IPSCCP in the default pass pipeline. Juneyoung On Wed, Aug 19, 2020 at 8:43 PM Alexander Cherepanov <ch3root at openwall.com> wrote: > On 19/08/2020 06.05, Juneyoung Lee via llvm-dev wrote: > > LangRef isn't clear

Hi Dustin, > I think I'm missing something basic about the semantics of returning an > aggregate type (in my case, a structure) from a function. Returning a > structure containing only compile-time constants is simple enough. But > I don't quite get how this works with a struct composed at run-time. If > I constructed it on the stack with alloca, would I be letting a

Many thanks for the recent answers to my question about pattern recognition. The hint to "grep" and the "pattern" argument brought me a big deal forward. # Now, I have a data frame: DATE <- c("1930-01-01", "1930-01-01", "1930-02-01", "1931-01-01", "1931-02-01", "1931-03-01") # almost all months until