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

James Molloy james.molloy at arm.com
Tue Oct 4 00:06:20 PDT 2011

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


So, I am sending out this proposal for feedback to the LLVM community. I've

pretty version of the proposal in PDF format and pasted a 80-column safe
text version



I'm looking forward to comments and feedback.





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





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

on the system that are visible to all threads.


What has this got to do with endianness?





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





In OpenCL, a pointer can have attributes attached, and this information

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

to the intrinsic.  An example encoding of this information is as follows:

!0 = metadata !{

  i32, ;; Tag = <OpenCL version number> using the official OpenCL version

  i1,;;Boolean value to specify that load is from host on true, device on

  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.







Micah Villmow



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

More information about the llvm-dev mailing list