similar to: Adding asan poison to Recycler and ArrayRecycler

On Mon, Aug 3, 2020 at 7:00 PM David Blaikie <dblaikie at gmail.com> wrote: > I don't have much personal interest here - but my understanding was > that there was/is a fair bit of pushback to fragmenting the > communications channels to discord before there's a more general > buy-in to switch over across the project? (perhaps I'm misremembering > the previous

On 22.08.2018 17:52, Ryan Taylor wrote: > This is probably going to effect on other backends and break llvm-lit > for them? Very likely, yes. Can you take a look at how big the fallout is? This might give us a hint about what other frontends might expect, and who needs to be involved in the discussion (if one is needed). Cheers, Nicolai > > On Wed, Aug 22, 2018 at 11:41 AM

Hi all, We’ve been having discussions over the last few weeks with stakeholders both inside and outside of AMD about where we could best have a dedicated and open discussion space for topics around the AMDGPU target. The conclusion was that we’d like to try the use of a category in the LLVM Discourse group, which is mostly used for MLIR discussion so far. I have started a Discourse topic with

There certainly is support; after all AMD supports both OpenCL and HIP (a dialect of C++ very close to cuda). AMD device libraries (in bitcode form) are installed when ROCm ( https://rocm.github.io/ ) is installed. AMD device libraries are mostly written in (OpenCL) C and open source at https://github.com/RadeonOpenCompute/ROCm-Device-Libs . They are configured by linking in a number tiny

Hi, I'd like to draw your attention to http://reviews.llvm.org/D18291, in which I propose a new intrinsic property for intrinsics that are lowered to instructions that mayStore, but are neither mayLoad nor hasSideEffects. This is relevant for AMDGPU, where we have store instructions that don't operate on pointers. The codegen backend understands these perfectly well as stores, and so

On 19.03.2016 14:47, Philip Reames wrote: > I'm generally in support of this change. I haven't looked at the patch > yet, but the direction seems worthwhile. > > Note that we already have a writeonly predicate in a few places in the > code (BasicAA being one). If we do introduce the new intrinsic > property, we should refactor all of these places to use the new >

On 03/21/2016 08:54 AM, Nicolai Hähnle wrote: > On 19.03.2016 14:47, Philip Reames wrote: >> I'm generally in support of this change. I haven't looked at the patch >> yet, but the direction seems worthwhile. >> >> Note that we already have a writeonly predicate in a few places in the >> code (BasicAA being one). If we do introduce the new intrinsic

Hi all, While working on some features for the AMDGPU backend -- specifically, explicit address components for image intrinsics, which involves generating both (a) a lot of intrinsics with different but somewhat regular parameter types, and (b) the patterns to select instructions for those intrinsics -- I got fed up with a lot of the TableGen bugs and limitations and set out to fix things.

One thing I want to mention. I believe in the current legacy pass manager implementation only one MachineFunction ever exists at a time. It is deleted before the next MachineFunction is created. This is very important for memory usage. I think the MachineOutliner being in the pipeline may create an exception to this. I think the initial version of retpoline used a ModulePass and that had to be

There's a regression in AMDGPU which would be nice to get resolved, see: https://bugs.freedesktop.org/show_bug.cgi?id=99078 https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.9/+bug/1656620?comments=all I think it's reasonably low-risk to back-port AMDGPU: Reduce the duration of whole-quad-mode AMDGPU: Do not clobber SCC in SIWholeQuadMode since they've been in trunk and

Hi, We're looking at what may be a real-life bug encountered by our compiler related to `undef` values and function calls. The input program effectively contains the expression clamp(v, x, x) expecting that the result will be equal to `x`, even when `v` is read from uninitialized memory. In the input language, `clamp` is a built-in, so this expectation is somewhat reasonable. In our

On Wed, Feb 19, 2020 at 3:51 AM Juneyoung Lee via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think not_poison (Johannes's used keyword) makes sense. We can simulate the original UB semantics by simply attaching it, as explained. > For the attributes other than nonnull, we may need more discussion; align attribute seems to be okay with defining it as poison, dereferenceable

On 02/19, Juneyoung Lee via llvm-dev wrote: > Hello, > > > Would it be correct to resolve this by saying that dereferenceable(N) > > *implies* not_poison? This would be helpful as a clarification of how > > it all fits together. > > Yes, I think it makes sense. I don't we should do that. Take the `gep inbounds` example: char* foo(char *arg) { return `gep

On Mon, Aug 17, 2020 at 7:14 PM Hal Finkel <hfinkel at anl.gov> wrote: > On 8/17/20 11:51 AM, Nicolai Hähnle wrote: > > Hi Hal, > > > > On Mon, Aug 17, 2020 at 2:13 AM Hal Finkel <hfinkel at anl.gov> wrote: > >> Thanks for sending this. What do you think that we should do with the > >> existing convergent attribute? > > My preference, which

Hi Hal, On Mon, Aug 17, 2020 at 2:13 AM Hal Finkel <hfinkel at anl.gov> wrote: > Thanks for sending this. What do you think that we should do with the > existing convergent attribute? My preference, which is implicitly expressed in the review, is to use `convergent` both for the new and the old thing. They are implicitly distinguished via the "convergencectrl" operand

Hi Nicolai, if you're open to it, I'd like suggest another smallish cleanup in libTablegen, namely doing something about the layering. Basicly what bit me a few times is that there is a `Main.cpp` file. This particular file adds CLI options such as -o, -d, -I. So if you build some out-of-tree tool and happen to link against `all` components because you're lazy, there is a high

Hi Artem, Thank you for your encouraging reply :) I have now cleaned up the first batch of changes and put them on Phabricator here: https://reviews.llvm.org/D43552 I've tried to keep individual changes small, and I've verified with `git rebase -x` that the build is good after each change. This first batch does not cause any changes in backend's generated files. [snip]>

Hi Jakub, On Tue, Jul 7, 2020 at 6:25 AM Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > There's a lot of heavily templated code in generic DomTee construction/updater, MemSSA updater, and GraphDiff that has become really hard to modify. For the context, Alina (cc'd) was recently looking into making the domtree code work with 'CFG views'; the basic idea is to

for example I want to insert a new machine bb “before” a specific machine bb. or split a mbb and keep the later one as the original one. (to keep the label/Blackadder's correct t) (or keep other property of mbb) so I need to transfer the original mbb's predecessor to the new mbb. Nicolai Hähnle <nhaehnle at gmail.com> 於 2020年3月13日 週五 23:57 寫道： > On Fri, Mar 13, 2020 at

Does anyone know whether there is yet support for math functions in AMD GPU kernels? In the NVIDIA world they provide the libdevice IR module which can be linked to an existing module containing the kernel. In other words they provide all math functions on IR level. NVIDIA even claims that libdevice is actually device specific (compute capability). I was wondering how that is done on the AMD