[llvm-dev] intrinsic for memory mapped IO?

Bruce Hoult via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 6 04:17:24 PDT 2016


On Sun, Jun 5, 2016 at 11:27 PM, Han Wang via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> Apologize if this is a dumb question, I am new to LLVM.
>
> I would like to use LLVM-IR to as an intermediate language to generate
> stream processing hardware


I assume you mean "to generate CODE FOR stream processing hardware.


>
>
Basically, at the very least, I would like to be able to input a stream of
> bytes into IR, and perform
> some operations on the bytes and output the stream bytes from IR.
>
> I am thinking of using the `load` and `store` instructions for the IO
> task, but I am not sure
> how to make the `load` instruction to load continuous stream of bytes from
> a memory address.
>
> To some extent, it is similar to use `load` to read from a memory mapped
> IO address to receive
> different bytes each time.
>
> I wonder if anyone has done similar things before, any pointer or
> suggestion would be much appreciated.
>

Unless I misunderstand you, memory mapped IO is exactly what you want.

The main thing is to prevent the optimizer from thinking that different
loads will return the same value and removing them, or assuming that later
stores will overwrite earlier stores and remove the earlier stores.

i.e. C code like this will work:

void stream(){
  volatile char *IN = (char*)0x100;
  volatile char *OUT = (char*)0x101;
  while (1) *OUT = *IN;
}

You can look at what clang creates from this, and generate similar IR
yourself

clang -S -Os stream.c -o stream.s -emit-llvm

define void @stream() #0 {
  br label %1

; <label>:1                                       ; preds = %0, %1
  %2 = load volatile i8* inttoptr (i64 256 to i8*), align 256, !tbaa !1
  store volatile i8 %2, i8* inttoptr (i64 257 to i8*), align 1, !tbaa !1
  br label %1
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160606/ac6b1909/attachment.html>


More information about the llvm-dev mailing list