[LLVMdev] [RFC] Proposal to make LLVM-IR endian agnostic

Tue Oct 4 10:07:39 PDT 2011

From: James Molloy [mailto:james.molloy at arm.com]
Sent: Tuesday, October 04, 2011 12:06 AM
To: Villmow, Micah; llvmdev at cs.uiuc.edu
Subject: RE: [RFC] Proposal to make LLVM-IR endian agnostic

Hi Micah,

I'm no core developer, but FWIW here are my thoughts:

I'm general I think the patch is too OpenCL oriented
[Villmow, Micah] I agree, but this is mainly to solve a problem that is unique to OpenCL or related technologies(CUDA, DirectCompute, etc...).
, and I have some niggling qualms about other parts. Specifically (comments inline):

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah
Sent: 03 October 2011 19:37
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] [RFC] Proposal to make LLVM-IR endian agnostic

One of the projects I am working on with others is to make LLVM-IR endian agnostic.

So, I am sending out this proposal for feedback to the LLVM community. I've attached
pretty version of the proposal in PDF format and pasted a 80-column safe text version
below.

I'm looking forward to comments and feedback.

-------------------------------------------------------------------------------
PROBLEM QUESTION:
-------------------------------------------------------------------------------
How does a vendor simplify the compiler stack across multiple target devices
by removing endianess from the IR representation?

This is not the question that your RFC answers. Your RFC answers a superset of just "represent endianness".
[Villmow, Micah] Maybe I didn't go into enough detail on how this proposal helps solve this problem. Currently
our compiler stack has to handle issues with big endian vs little endian devices along with 32bit vs 64bit devices(which is outside of this scope).  If we want to have a common binary that we can use to compile for all devices, then we must store both versions of the LLVM-IR, increasing binary size and compile time. By abstracting away endianness representation, two of the 4 variations are unified, allowing the fat binary to store 1 LLVM-IR representation for each bitness instead of 2. So by abstracting endian assumptions out of the LLVM-IR, we are simplifying the compiler stack.

-------------------------------------------------------------------------------
DEFINITIONS:
-------------------------------------------------------------------------------
Global Memory - Memory that is visible to all threads in a process/program,
e.g. video ram. This includes all read-only, write-only and read-write memories
on the system that are visible to all threads.

What has this got to do with endianness?
[Villmow, Micah] This just defines the type of memory we are interested in. Other types of memory are not covered by this proposal, as they should not have this problem. For example, endianness agnostic load/stores to private memory are meaningless as it is only visible within a thread.

-------------------------------------------------------------------------------
INTRINSICS:
-------------------------------------------------------------------------------
This proposal introduces new sets of intrinsics, two load intrinsics and two
store intrinsics. The sets are as follows:
declare <type> @llvm.portable.load.e.<type>(<type>* ptr, , i32 alignment,
i1 host, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread)
// little endian load

declare <type> @llvm.portable.load.E.<type>(<type>* ptr, i32 alignment,
i1 host,  i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread)
// big endian load

declare void @llvm.portable.store.e.<type>(<type> data, <type>* ptr,
i32 alignment, i1 host,  i1 atomic, i1 volatilei1 nontemporal,
i1 singlethread) // little endian store
declare void @llvm.portable.store.E.<type>(<type> data, <type>* ptr,
i32 alignment, i1 host, i1 atomic, i1 volatile, i1 nontemporal,
i1 singlethread) // big endian store

*         I don't like the 'e'/'E' representation. If there were only little or big endian loads throughout an IR file, it wouldn't be obvious to me what the 'e'/'E' meant. It's only seeing the two in tandem where it jumps out at me. I'd prefer the standard 'le'/'be'.
[Villmow, Micah] Good suggestion, I was using the 'e' and 'E' as that is what is in the target data description from the LLVM spec.

*         You've put the OpenCL concept of "host" and "device" in a supposedly target-agnostic IR. Why should there be only one device? More importantly, why is host/device an attribute of the load or store as opposed to the pointer to load/store to? Does it semantically make sense to have both a host load and a device load of the same memory location in the same module?
[Villmow, Micah] Abstracting LLVM-IR so it can encode multiple device execution information from a single compilation unit is outside the scope of this proposal, hence the single device. The reason for not adding the attribute to the pointer is that each load/store can be unique in how to represent the endianness of the memory it points to. As for the third question, it isn't a host load and a device load, it is a load with host endianess and a load with device endianess. A hypothetical example of this is a simple embedded co-processor attached to a general purpose processor(i.e. AMD's Torrenza initiative) where the co-processor did not have hardware to convert between the endianness but memory spans across its own memory and the system memory. In this case, the compiler when it generates executables needs to make sure that loads from the host have memory ordered correctly for the device. Again, this is just an example, but a possible valid situation.
-------------------------------------------------------------------------------
POINTER ATTRIBUTES:
-------------------------------------------------------------------------------
In OpenCL, a pointer can have attributes attached, and this information needs
to be encoded. In LLVM, the method of encoding extra information is via
metadata nodes and this is used so that the intrinsic do not need to be
modified to add extra information. One example of this is the endian(host)
attribute that can be attached to a pointer argument(see 6.10.3 of OpenCL
1.1 spec). This information can be encoded in a metadata node which is attached
to the intrinsic.  An example encoding of this information is as follows:
!0 = metadata !{
  i32, ;; Tag = <OpenCL version number> using the official OpenCL version macro
  i1,;;Boolean value to specify that load is from host on true, device on false
  metadata ;; List of attributes for this intrinsic instruction
}

Does this subsection add anything extra to the RFC? It talks about a format for metadata, but doesn't appear to really add any suggestions or requirements for changing LLVM IR.
[Villmow, Micah] Your right, this is more on how to encode pointer information, this can be ignored.

If your intention was just to make the IR endian-agnostic, I don't see why you wouldn't just propose an extra attribute on the load/store instructions (load be %0, load le %0) instead of recreating all loads and stores in a new form and having to make all passes interact with them.
[Villmow, Micah] While we could go this route, this would make the endian agnostic IR compatible with LLVM-IR passes, which we don't want to do, hence the use of intrinsic. Basically we want the endian agnostic IR to be mostly compatible with LLVM-IR, but will require a transformation pass to generate the correct load/store instructions for the device it will be generated for. I believe there was other reasons brought up by other contributors, but they escape me right now.

My general summary is that I think your suggestions take a "somewhat language-agnostic and somewhat target-agnostic" IR and turn it into a "somewhat language-dependent and more target-agnostic" IR, by embedding OpenCL specifics. I'm not sure I think that's the best way to go.
[Villmow, Micah] That is correct, that is basically what we are attempting to do. We want a single IR that can be used across multiple devices for OpenCL. If this is something that can be modified to be less language dependent but keep the target agnostic and fulfill our needs, then we are willing to go down that path. This is why we believe involving the LLVM community is important so we can get this kind of feedback and hopefully agree on something that we can use, but other non-related projects can also use.

Cheers,

James

Thanks,
Micah Villmow

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/104c13eb/attachment.html>