similar to: AMDGPU and math functions

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

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

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

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

Conditional on the target supporting cmov? Though that's probably not optimal. On Wed, Feb 5, 2020, 7:47 AM Nicolai Hähnle <nhaehnle at gmail.com> wrote: > Hi Ryan, > > On Mon, Feb 3, 2020 at 7:08 PM Ryan Taylor via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > SimplifyCFG FoldTwoEntryPhiNode looks to simplify all 2 entry phi nodes > in a block, if it

On 22.08.2018 13:29, Ryan Taylor wrote: > The example starts as SPIR-V with the NoContraction decoration flag on > the fmul. > > I think what you are saying seems valid in that if the user had put the > flag on the fadd instead of the fmul it would not contract and so in > this example the user needs to put the NoContraction on the fadd though > I'm not sure

Any comments at all on this? Chandler perhaps? I've since dug a bit further, and it seems like the template-based solution wouldn't work anyway because DLL loading on Windows can't do the required commoning. So the general approach taken in https://reviews.llvm.org/D62802 seems to be the only technically viable path forward, though it would still be good to get an outside look at the

Hi I want to ask a question. (Maybe it is a trivial question.) I found that there is transferSuccessors() in MachineBasicBlcok So that when manipulating MachineBasicBlock, we can use transferSuccessors to update the CFG easily. Why there is not transferPredecessors in MachineBasicBlcok ? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL:

Some background: We have an issue with in loop values being correctly marked uniform but the out of loop uses can be non-uniform. Currently the out of loop users are not marked as divergent because the in loop value is uniform inside the loop. We have gotten around this problem for the moment by applying LCSSA which inserts a PHI in the loop exit for the in loop uniform value that allows the

Is there any specific documentation on this? Is there a point of contact for this file that I might bug? So I have an instruction that needs noops inserted and it appears that the noops are being inserted in the EmitSchedule function of the PostRAScheduler. From the loop in EmitSchedule it looks like it's inserting noops whenever SUnit is NULL. I don't see anything in the DAG that appears

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

On 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote: > So I have a test case where: > > %20 = fmul nnan arcp float %15, %19 > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > is being contracted in DAG to fmad. Is this correct since the fmul has > no reassoc or contract fast math flag? By having the reassoc and contract flags on fadd, the frontend is

Are all the records collected as they are parsed, with template parameter substitution and lets, and *then*, after all records are collected, a "pass" is made to calculate the inter-field expressions? Once I understand this, I will add a section to the new guide to explain it. I presume it is the case that this behavior should be publicized. It also appears to be the case that a record

Hi all! Is it possible somehow to specify *order* of object files to be put to executable file? For example, I want to put obj1.o and obj2.o somewhere at the beginning, so when executable file would be mapped to memory, this code would be accessed quickly.

We've relaxed `atomicrmw xchg` to support floating point types but not cmpxchg -- the cmpxchg comparison behavior is not a floating point comparison, so that would be potentially misleading. I'd say adding the assertion is a good idea. Cheers, Nicolai On Thu, Aug 13, 2020 at 10:59 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Does the code generator

Dear LLVM developers, My goal is to write LLVM Machine IR (MIR) passes to analyze the assembly source code. But it seems I need to find a way to translate the handwritten assembly code into MIR format first. Is there any materials, or any modules in LLVM source code, that can help to translate assembly code into LLVM MIR for analysis? Or is there any easier ways to analyze assembly code in MIR

Hi Craig, The review for the similar GPU problem is now up here: https://reviews.llvm.org/D85603 (+ some other patches on the Phabricator stack). >From a pragmatic perspective, the constraints added to program transforms there are sufficient for what you need. You'd produce IR such as: %token = call token @llvm.experimental.convergence.anchor() br i1 %c, label %then, label %else

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.

A question for those of you who have developed complex TableGen files: Do you think a trace facility would be useful during debugging? The idea is to add a new statement to TableGen along these lines: trace tag : value1, value2, ... ; When encountered, the TableGen parser would display the tag along with the values of the specified value1, value2, etc. The tag is an identifier that makes it

Did this conversation reach a conclusion? My ad hoc tally says that a slight majority of the responders preferred to fully brace statements and no one wanted to totally eliminate braces. The technical arguments for fully braced statements were 1) it's considered a slightly safer coding style and 2) commit diffs with fully braced statements may be slightly more to the point. I didn't