Hi Erik,
Now I remember more of the earlier discussion regarding this.
There was an idea to compile the required parts of the lib from the
sources during the kernel compilation, not having bitcode libs
at all.
It should work fast enough when compiling only the needed APIs,
especially with the current kernel compiler cache in place its
overhead should not be significant.
On 10/26/2014 03:01 PM, Erik Schnetter wrote:
> In the latter case, one would also need to distinguish at run time on
> what architecture one is running, presumably automatically, so that
> optimal kernel code can be generated.
Detection of the CPU features is important part to make this work.
Either at the runtime or install time and stored to a configuration file
locally to the machine.
> Alternatively, we could support different device types, one for each
> CPU architecture. This may be more elegant than trying to insert a
> distinction between different CPU architectures and keeping this
> invisible to the user ("why does this binary kernel not work any
> more?"). In fact, the longer I think about this the more I like this
> idea -- making CPU architectures visible to the end user seems a good
> idea.
I'm not sure what you mean by making the architectures visible to the
end user here. But it's a good point that the upcoming proper binary
format (likely derived from the current kernel cache directory structure
simply by archiving the contents) should include the required target
info as a metadata next to the cached binary.
In your cluster scenario, though, the kernel compiler cache that is
based in the home directory should work now as the binaries are
compiled separately for each machine and stored locally (assuming
there are home directories in the cluster's machines, that is).
--
--Pekka
------------------------------------------------------------------------------
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel
