Thanks.
And a few questions about compiler options:
1) You've mentioned two options for offloading:
-foffload-target=<set of targets> - to specify targets for offloading
-foffload-target-<target name>=<set of options> - to specify
compiler options for different targets
Do we really need two options to set up offloading?
What do you think about, in my opinion, more compact way:
-foffload-<target name> - if I want to offload for 'target name',
but I don't want to specify any options
-foffload-<target-name>=<set of options> - enable offloading for
'target name' and set options
And compilation for several targets would look like:
gcc -fopenmp -foffload-mic="-O3 -msse -m64" -foffload-ptx
-foffload-hsail="-O2 -m32" file.c
2) If user doesn't specify target options directly, is target
compilation done without any option or compiler uses those host
options which are suitable for target?
3) Am I understand right, that options for different targets should be
stored in different sections in fat object file, and than lto frontend
should read theese options and run target compilation with them?
On Thu, Nov 7, 2013 at 7:42 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Thu, Nov 07, 2013 at 07:36:06PM +0400, Andrey Turetskiy wrote:
>> > Note, configure options should be either --with- or --enable- prefixed.
>> > Plus, it is probably better to use configuration triplets there.
>>
>> Do you mean smth like this:
>> configure --build=x86 --host=x86 --target=x86,mic,ptx
>> Then "make" should build 3 gcc: x86 native and crosses for mic and ptx.
>
> It can very well be just that the user should first
> mkdir ~/whatever-1; cd ~/whatever-1
> .../configure --target x86_64-k1om-linux --prefix=/whatever
> make; make install
> mkdir ~/whatever-2; cd ~/whatever-2
> .../configure --target ptx-none --prefix=/whatever
> make; make install
> and then
> mkdir ~/whatever-3; cd ~/whatever-3
> .../configure --with-offload-targets=x86_64-k1om-linux,ptx-none
> --prefix=/whatever
> ?
> At least initially, because building several different compilers in one
> build directory would be kind of interesting, I'm not saying not doable,
> but there are other issues to be solved first.
>
> Jakub
--
Best regards,
Andrey Turetskiy
