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

[James Molloy]

Hi Micah,

 

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

 

I'm general I think the patch is too OpenCL oriented, 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".

 

----------------------------------------------------------------------------
---

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?

 

----------------------------------------------------------------------------
---

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'.

.         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?

 

----------------------------------------------------------------------------
---

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.

 

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.

 

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.

 

Cheers,

 

James

 

Thanks,

Micah Villmow

 

 

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