similar to: [LLVMdev] Aggregate store/load optimization

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-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

----- 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 >

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

----- 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 >

----- 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,

On Sun, Aug 16, 2015 at 9:49 PM deadal nix <deadalnix at gmail.com> wrote: > 2015-08-16 21:47 GMT-07:00 Eric Christopher <echristo at gmail.com>: > >> >> >> On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Chiming in with http://reviews.llvm.org/D10725 >>> >>>

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.

Hi all, As most of you may now, LLVM is completely unable to do anything reasonable with aggregate load/stores, beside just legalize them into something in the backend. This is not a good state of affair. Aggregate are part of LLVM IR, and as such, LLVM should do something about them. That is a bit of a chicken and egg issue: front end just implement their own tricks to avoid aggregate or plain

OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) is unecessary and the SelectVT is nto the right type (as it is called with incorrect parameter). Here is a patch so it won't generate a loop. I ran make check and it doesn't look like anything is broken. 2014-07-07 11:36 GMT-07:00 Matt Arsenault <arsenm2 at gmail.com>: > > On Jul 5, 2014, at 7:14 PM,

OK, so in you case, you want DAG.getSExtOrTrunc(SetCC, DL, SelectVT) to tunc the result from i64 to i32 on 64 bits targets, if I understand correctly. 2 questions: - Why not generating a selectcc node directly ? It avoid having to mess up with intermediate values. - Why calling getSetCCResultType(VT) ? VT is not the type of a parameter of setcc, and this looks incorrect to me. 2014-07-05 0:34

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

On Aug 18, 2015, at 10:41 PM, deadal nix <deadalnix at gmail.com> wrote: > Let's not get this die. The C API is too valuable to let this die. > > I propose the following plan: > - Add tests for the current API. This will allow to make sure that everything works and would ensure that changes are made intentionally, nto accidentally. > - For area that do not exist in the

Hi, I'm working on a target which have a variable size for CC (the same size as the arguments). As a result getSetCCResultType, return a variable size. In this commit, at the line DAG.getSExtOrTrunc(SetCC, DL, SelectVT), on my target, you end up generating the Node you are replacing, and so creating a loop in the DAG, which give a whole new meaning to the A in the acronym. Subsequent code

On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Chiming in with http://reviews.llvm.org/D10725 > > Being able to read and generate IR is at least some very basic thing we > can agree on is needed. Can we get some testing for it ? Personally I don't > really mind if this is going to be stable or not, but at least, having some

This is about the best idea. There's no way to take the non-temporary md nodes back to temporary. -eric On Mon, Oct 5, 2015 at 10:12 AM Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Abstractly, (I don't get inside this code as much as I should) debug info > works on a translation-unit basis, not a function basis, so regenerating a > single

2015-08-17 13:47 GMT-07:00 David Blaikie <dblaikie at gmail.com>: > > > >> >> I'd propose that the only 100% strict rule should be that if the ABI/API >> changes, it is done in a way that *loudly* breaks old programs -- e.g. they >> fail to compile, link, or run (depending on how the other-lang wrappers are >> accessing the API functions) -- not

On 07/08/2014 03:20 PM, Matt Arsenault wrote: > Alternatively maybe this should only be done if the setcc type is the > same as the sext result? I think we should actually do this. If you need to convert the setcc result after, you aren't really gaining anything by doing this transformation -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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