search for: hsail

Hi, AMD would like to propose including an LLVM backend for the HSAIL target. Patches for review are attached and can also be found at https://github.com/HSAFoundation/HLC-HSAIL-Development-LLVM/ on the hsail-review branch. Most of the recent work is visible on the hsail-1.0f branch, which is based on an LLVM commit approximately 1 month before 3.6 branched. The...

> On Jun 22, 2015, at 9:31 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > This part is scary. > > Having a third party library dependency is very undesirable from a testing perspective. > > I agree, but it’s what we are stuck with for now. It’s an optional dependency now, so most people building LLVM won’t need to worry about it > > One of

...t; >> Yes, it would. I’ve always imagined this to a be a large undertaking >> though > I'd agree on the scope, but it also seems fairly straight forward. If > this becomes a serious issue, this seems like a workable approach. This sounds similar to a problem we face in the HSAIL backend. NULL is not a constant in HSAIL, but an instruction that returns "a constant address that is guaranteed to be invalid for the given address space". The instruction will always return the same constant, so it can be stored and used in a comparison. So in HSAIL, zero is a valid...

...il. It's easier to read > and reply to. Sorry about that! Here's the plain text (I hope!): Hi all, OpenCL 2.0 introduced the notion of memory scope in atomic operations to global memory. These scopes are a hint to the underlying platform to optimize how synchronization is achieved. HSAIL also has a notion of memory scopes that is compatible with OpenCL 2.0. Currently, the LLVM IR uses a binary value (SingleThread/CrossThread) to represent synchronization scope on atomic instructions. This makes it difficult to translate OpenCL 2.0 atomic operations to LLVM IR, and also to imple...

...nce the representation of memory scopes in LLVM IR to > allow more values than just the current two. The intention of this > email is to invite comments on our proposal. There are some discussion > before and it can be found here: > https://groups.google.com/forum/#!searchin/llvm-dev/hsail/llvm-dev/46eEpS5h0E4/i3T9xw-DNVYJ > <https://groups.google.com/forum/#%21searchin/llvm-dev/hsail/llvm-dev/46eEpS5h0E4/i3T9xw-DNVYJ> > > Here is our new proposal: > > ================================================================= > We still let the bitcode store memory sc...

...ation use the same scope throughout the application, i.e., all threads running on all agents. So it is not okay for the compiler to "promote" the scope in just one kernel unless it has access to the entire application; the result is undefined. This is true for OpenCL source as well as HSAIL target. This may change in the near furture: HRF-Relaxed: Adapting HRF to the complexities of industrial heterogeneous memory models http://benedictgaster.org/?page_id=278 But even then, it will be difficult to say if the same models can be applied to heterogeneous systems that don't resemb...

...loop is currently lost forever. The Design Space of Solutions ============================= The relevant high-level languages are structured programming languages, where the behavior of subgroups falls out quite naturally. Needless to say, we cannot rely on structured control flow in LLVM IR. HSAIL defines subgroups as forking at branches and joining at the immediate post-dominator. It also attempts to define restrictions on program transformations in terms of immediate dominators and post-dominators. I am not certain that this definition is sound in all cases, and it is too restrictive i...

...d these patches are only meant to start a more detailed discussion on the way forward. One big issue is the absence of any backend that actually makes use of intermediate synchronization scopes. This work is meant to be just one part of the ground work required for landing the much-anticipated HSAIL backend. Also, more work might be needed for emitting atomic instructions via Clang. The proposed syntax for synchronization scope is as follows: 1. Synchronization scopes are of arbitrary width, but implemented as unsigned in the bitcode, just like address spaces. 2. Cross-thread is defa...

> On Jan 7, 2015, at 3:10 PM, Philip Reames <listmail at philipreames.com> wrote: > > > On 01/07/2015 12:05 PM, Matt Arsenault wrote: >> >>> On Jan 7, 2015, at 2:55 PM, Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: >>> >>> >>> On 01/07/2015 11:52 AM, Matt Arsenault wrote:

...We would like to enhance the representation of memory scopes in LLVM IR to allow more values than just the current two. The intention of this email is to invite comments on our proposal. There are some discussion before and it can be found here: https://groups.google.com/forum/#!searchin/llvm-dev/hsail/llvm-dev/46eEpS5h0E4/i3T9xw-DNVYJ Here is our new proposal: ================================================================= We still let the bitcode store memory scopes as *unsigned integers*, since that is the easiest way to maintain compatibility. The values 0 and 1 are special. All other valu...

...t; [Network —> ] System —> AllThreads —> ThreadGroup —> SingleThread ? > > > Sadly, I don't think this will work. In particular, there are > real-world accelerators with multiple tiers of thread groups that are > visible in the cache hierarchy subsystem. The HSAIL 1.0 provisional spec has the following scopes: workitem, wavefront, workgroup, component, system. A component is anything that supports the HSAIL instruction set and can execute commands dispatched to it. I am not an authority on this, but to me, it is conceivable that there could be other scop...

.... We would like to enhance the representation of memory scopes in LLVM IR to allow more values than just the current two. The intention of this email is to invite comments on our proposal. There are some discussion before and it can be found here: https://groups.google.com/forum/#!searchin/llvm-dev/hsail/llvm-dev/46eEpS5h0E4/i3T9xw-DNVYJ Here is our new proposal: ================================================================= We still let the bitcode store memory scopes as "unsigned integers", since that is the easiest way to maintain compatibility. The values 0 and 1 are special. All...

...nhance the representation of memory scopes in LLVM IR to allow more values > than just the current two. The intention of this email is to invite > comments on our proposal. There are some discussion before and it can be > found here: > https://groups.google.com/forum/#!searchin/llvm-dev/hsail/llvm-dev/46eEpS5h0E4/i3T9xw-DNVYJ > > Here is our new proposal: > > ================================================================= > We still let the bitcode store memory scopes as "unsigned integers", since > that is the easiest way to maintain compatibility. The v...

+1 to lib/Target/SPIRV/(Reader|Writer) I really like this idea. I’ve talked with some people on both the LLVM and Khronos sides and I really think adding SPIR-V support to LLVM as an optional program serialization format would be fantastic. I think it would make it even easier for LLVM-based tools to be integrated into GPU authoring and execution pipelines. I’m really excited to see this moving

...a proper subset > of) the scope represented by a smaller value." This would also > imply > that the value used for single-thread scope must be the largest > value used by the target. > This constraint on "nesting" is easily satisfied by HSAIL (and also > OpenCL), where synchronization scopes increase from a single > work-item to the entire system. But it is conceivable that other > targets do not have this constraint. For example, a platform may > define synchronization scopes in terms of overlapp...

Hi Mr. Liu, Thanks for your quick reply. I compiled the code with the libclc_trunk and linked the bitcode file under $LIBCLC_DIR/built_libs/tahiti-amdgcn--.bc. After looking into the libclc, it is currently using the new workitem intrinsics (commit ba9858caa1e927a6fcc601e3466faa693835db5e). In the linked bitcode ($LIBCLC_DIR/built_libs/tahiti-amdgcn--.bc), it has the following code segment,

On Jun 25, 2013, at 1:45 AM, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > Is there some sort of restriction over class length names in td files. Only your own sanity, as far as I know. > For e.g. something like below gives an abort with tablegen. The abort goes away when I reduce the name "my_target_intrinsics_class..." to something shorter. I have not

Hi Is there some sort of restriction over class length names in td files. For e.g. something like below gives an abort with tablegen. The abort goes away when I reduce the name "my_target_intrinsics_class..." to something shorter. I have not counted the exact length limit though. Is this a known issue? defm target_intrinsic:

Hi Sameer, > On Jan 5, 2015, at 4:51 AM, Sahasrabuddhe, Sameer <Sameer.Sahasrabuddhe at amd.com> wrote: > > Right. The second version of my patches fixes the bitcode encoding. But now I see another potential problem with future bitcode if we require an ordering on the scopes. What happens when a backend later introduces a new scope that goes into the middle of the order? If they