search for: deadalnix

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.

On Sun, 1 May 2016 at 16:12 Amaury SECHET <deadalnix at gmail.com> wrote: > Some update on this. > > 2016-04-12 18:48 GMT-07:00 Andrew Wilkins <axwalk at gmail.com>: > >> On Wed, 13 Apr 2016 at 09:38 Amaury SECHET <deadalnix at gmail.com> wrote: >> >>> I'd be happy to do it, but this is a bit much...

...7:00 Nirav Davé <niravd at google.com>: > You can always explicitly add D to the worklist when you make the > transformation with AddToWorklist. Presuambly this was the cause for your > infinite loop. > > -Nirav > > > On Mon, May 22, 2017 at 2:07 PM, Amaury SECHET <deadalnix at gmail.com> > wrote: > >> The root problem is that, when A gets modified, D doesn't get added back >> to the worklist. I could match the pattern on A, but the problem remains: >> when D gets modified, A do not get added back tot he worklist. >> >> I also...

...re using a normal value. (Actually, I wonder if it would be possible to represent x86's EFLAGS.CARRY as a 1-bit subreg of EFLAGS, and use that on input to X86ISD::ADC; that may allow cheaper spills/reloads if it only has to save the one bit?). On Wed, Feb 8, 2017 at 7:28 PM, Amaury SECHET <deadalnix at gmail.com> wrote: > Well I don't think this would break most backend. The opcode is generate > only if the backend allows so to boot, so many backend actually do not use > it at all. > > Anyway, changing these opcode is kind of much broader scope than what I > anticipat...

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

...y ? 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 GMT-07:00 Matt Arsenault <arsenm2 at gmail.com>: > > On Jul 4, 2014, at 8:18 PM, deadal nix <deadalnix at gmail.com> wrote: > > > 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, S...

On Wed, 13 Apr 2016 at 09:38 Amaury SECHET <deadalnix at gmail.com> wrote: > I'd be happy to do it, but this is a bit much high level for me to be > actionable. Can you explain me what I should do to reintroduce them int he > debian packaging ? > On the CMake side, I'm not sure. I think it's just a matter of using the &quo...

...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, deadal nix <deadalnix at gmail.com> wrote: > > > 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 avoi...

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

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

...ransform doesn't match. That is not really relevant to the issue here, because the x86 backend does work even if the transform gets triggered (replacing the final store with "store i64 %add37, i64* %r, align 8" will make this happen) On Tue, Feb 7, 2017 at 5:44 PM, Amaury SECHET <deadalnix at gmail.com> wrote: > Making this a value instead of a glue looks like a good longer term > solution, but it doesn't quite cut it as a short term one. It would require > to change a fair amount of code in the DAG stack, plus in each backend. > > @James, > do you think doi...

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

----- 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/sto...

...> back. Maybe we can delay it to !DCI.isBeforeLegalizeOps()? That would at > least let the first DAG combine and the post type legalization DAG combine > see the add, 1. > > > > > > > > +Sanjay as well > > > > > > > > From: Amaury Séchet <deadalnix at gmail.com> > > Sent: Monday, August 26, 2019 10:48 AM > > To: Topper, Craig <craig.topper at intel.com>; llvm-dev at redking.me.uk; > efriedma at quicinc.com; lebedev.ri at gmail.com; llvm-dev < > llvm-dev at lists.llvm.org> > > Subject: LLVM X86 backend co...

...r has already been turned into a constant pool load by then so it’s a little difficult to get back. Maybe we can delay it to !DCI.isBeforeLegalizeOps()? That would at least let the first DAG combine and the post type legalization DAG combine see the add, 1. +Sanjay as well From: Amaury Séchet <deadalnix at gmail.com> Sent: Monday, August 26, 2019 10:48 AM To: Topper, Craig <craig.topper at intel.com>; llvm-dev at redking.me.uk; efriedma at quicinc.com; lebedev.ri at gmail.com; llvm-dev <llvm-dev at lists.llvm.org> Subject: LLVM X86 backend combineIncDecVector's transform Hi all...

Hi, I'm working with workload where the bottleneck is cryptographic signature checks. Or, in compiler terms, most large integer operations. Looking at rL296252 , the state of affair in that area degraded quite significantly, see test/CodeGen/X86/i256-add.ll for instance. Is there some kind of work in progress here and it is expected to get better ? Because if not, that's a big problem.

...s.llvm.org > wrote: > 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 ? > > > 2015-08-17 12:16 GMT-07:00 deadal nix <deadalnix at gmail.com>: > >> >> >> 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: >>> &...

Hi all, As you knwo already, I'm trying to change DAGCombiner so that it process the nodes in topological order. Doing so is not difficult per se, but this creates various improvements and regression to the existing test suite. I'd like to work through as many of the regressions as possible ahead of time. One source of such regressions is combineIncDecVector in the X86 backend. It

----- 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, because the RFC below is not detailed and assume everyone &g...

The root problem is that, when A gets modified, D doesn't get added back to the worklist. I could match the pattern on A, but the problem remains: when D gets modified, A do not get added back tot he worklist. I also considered ding several round of DAGCombine, but it is very easy to run into infinite loops, even with a fair amount of sanity checks. 2017-05-22 7:30 GMT-07:00 Nirav Davé