[PATCH] D22822: Adjust coercion of aggregates on RenderScript

Stephen Hines via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 26 23:46:17 PDT 2016


srhines added a comment.

In https://reviews.llvm.org/D22822#496789, @t.p.northover wrote:

> > To run a compute kernel, the RenderScript runtime iterates over its input and output buffers using a stride equal to the size of the underlying type and invokes the kernel function on entries in the buffer. Disagreement between the kernel and the the runtime on the sizes of these types can lead to incorrect output,
>
>
> What language is the runtime written in? I assume LLVM-aware C++ (so it inspects the llvm::Function's parameters before JITing some appropriate loop to do the iteration code)? I think it would be best to pass the stride information through a side channel rather than constraining the front-end to produce sub-optimal code (perhaps a global variable with a special name related to the kernel?).


The runtime is written in a combination of LLVM-aware C++ and raw LLVM bitcode. The problem is that the source language is LLVM bitcode that was/is already lowered. Once Clang has decided to expand these types, the actual backend can't determine the original data size. If we could go back and side-channel the size information, we certainly would, but I don't think that is possible right now. I can talk to the rest of the RS team to see if they would mind passing the information differently going forward, but existing code/devices has to work this way.

> The runtime dictating the ABI like that seems backwards to me. Ideally you'd start with some given set of functions, decide what the fastest way to run them is, and make sure the runtime is capable of supporting that.

> 

> Cheers.

> 

> Tim.





https://reviews.llvm.org/D22822





More information about the llvm-commits mailing list