search for: whatmannerofburgeristhis

...> > Cheers, > Nicolai > > > > > > > Do you run “codegen” IR passes with regular IR passes? If so, do you > mind sharing the use cases? I might have missed this use case. > > > > ________________________________________ > > From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on behalf of > Matt Arsenault <arsenm2 at gmail.com> > > Sent: Wednesday, July 15, 2020 9:31 AM > > To: Chen, Yuanfang > > Cc: Robinson, Paul; llvm-dev at lists.llvm.org > > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven &g...

Hi Matt, which analysis is this? ________________________________________ From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on behalf of Matt Arsenault <arsenm2 at gmail.com> Sent: Tuesday, July 21, 2020 12:02 PM To: Craig Topper Cc: Chen, Yuanfang; Nicolai Hähnle; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new pass manager > On Jul...

...e more sense to run all passes within a single pipeline. Cheers, Nicolai > > Do you run “codegen” IR passes with regular IR passes? If so, do you mind sharing the use cases? I might have missed this use case. > > ________________________________________ > From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on behalf of Matt Arsenault <arsenm2 at gmail.com> > Sent: Wednesday, July 15, 2020 9:31 AM > To: Chen, Yuanfang > Cc: Robinson, Paul; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new pass manager > &g...

> On Jul 15, 2020, at 12:28, Chen, Yuanfang <Yuanfang.Chen at sony.com> wrote: > > In codegen with NPM, I've made all codegen passes (IR or MIR pass) to be only driven by `llc`. Both due to the way NPM registering pass (on-demand&dynamic instead of static initialization in Legacy PM), and reduce the confusion about which tool (`llc` or `opt`) to test codegen IR passes. >

On Aug 8, 2013, at 7:22 , Micah Villmow <micah.villmow at smachines.com> wrote: > It was commited at one point, however due to personal matters, I was not able to respond to issue that arose and the changes were reverted. > The longer explanation for why it was reverted can be read here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/055098.html Actually you never

...after knowing this, and removing those tests doesn't seem like a great solution. What are your thoughts? For now, I think I can work around my original issue since the CUDA driver seems to optimise away the additional ADD in most cases. ________________________________ Van: Matt Arsenault <whatmannerofburgeristhis at gmail.com> namens Matt Arsenault <arsenm2 at gmail.com> Verzonden: maandag 23 maart 2020 19:05 Aan: Thomas Faingnaert <thomas.faingnaert at hotmail.com> CC: Johannes Doerfert <johannesdoerfert at gmail.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Onder...

The associated patch caused a compilation problems on Hexagon: https://bugs.llvm.org/show_bug.cgi?id=43302 The splitting of a live interval should not be done automatically upon creation. Calling LIS->getInterval(Reg) should not go around changing the code behind the scenes. There is already a function “splitSeparateComponents” that does that. It should be added where it’s missing. --

I am using some non-allocatable RegisterClasses to define lists of registers that are used for various non-allocation-related processing in the back end. For example, we have a post-allocation functional unit selection pass that is guided by the register assignment, which does things like 'myRegClass.contains(Reg)' to see if a register is in the set of registers accessible by a given unit.

> On Dec 5, 2017, at 13:53, Matt Arsenault <arsenm2 at gmail.com> wrote: > > > >> On Dec 5, 2017, at 02:51, Haidl, Michael via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi dev list, >> >> I am currently exploring the integration of AMDGPU/ROCm into the PACXX project and observing some

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value

> On Dec 6, 2017, at 02:28, Haidl, Michael <michael.haidl at uni-muenster.de> wrote: > > The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1. This sounds possibly problematic to me. The IR should be created with the correct address space to begin with. Changing this in the middle sounds suspect. > After this