llvm dev - Oct 2011 - [LLVMdev] [RFC] Proposal to make LLVM-IR endian agnostic

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>

I wonder if this could be handle specifying that certain address spaces
have one or another endianness, which is not necessarily the same as the
processor endianness.

Your main requirement seems to be that you need to access to banks of
memory, with different endianess, and that you the first stage IR to be
able to be run on either endianness processor, without change. I would
assume that any given pointer points either to host memory, device
memory, or private memory, and that these pointers never get mixed. This
seems an ideal use of memory spaces.

  Tom

> -----Original Message-----
> From: Tom Prince [mailto:tom.prince at ualberta.net]
> Sent: Tuesday, October 04, 2011 10:59 AM
> To: Villmow, Micah; James Molloy; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] [RFC] Proposal to make LLVM-IR endian agnostic
> 
> 
> I wonder if this could be handle specifying that certain address spaces
> have one or another endianness, which is not necessarily the same as
> the
> processor endianness.
> 
> Your main requirement seems to be that you need to access to banks of
> memory, with different endianess, and that you the first stage IR to be
> able to be run on either endianness processor, without change. I would
> assume that any given pointer points either to host memory, device
> memory, or private memory, and that these pointers never get mixed.
> This
> seems an ideal use of memory spaces.
[Villmow, Micah] This was brought up but breaks down when you have 
different endianness memory operations to the same pointer. For example,
the program wants a big endian load from offset 0x100 from pointer 'a' 
and a little endian load from offset 0x100 of pointer 'a' from the
global
address space. Since LLVM correctly stores the address space in the type, 
this would require multiple types for each pointer, duplicating information
and requiring casts between address spaces(which is illegal). The assumption
that device and host memory are unique is not always valid, as they are
both under the more general 'global' address space. Since the compiler
does
not know which part of global memory maps to host and which part to device
unless the programmer makes it explicit, there is a need to specify it in the
instruction.
> 
>   Tom