thr3ads.net - llvm dev - [LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor [Mar 2013]

If this information is useful, please help other people find it:
Share via:

Jiong Wang

2013-Mar-01 07:34 UTC

[LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

On 03/01/2013 02:57 PM, Hal Finkel wrote:
Hi Hal,

   thanks for feedback.> Jiong, I am happy to see the Tile backend being offered for upstream
inclusion. Among other things, in the long run, this may help inform and
motivate many-core capabilities in LLVM.
>
> First, can you elaborate on the future maintenance and development plans
for the target code? Do you plan to add SIMD support? Atomic memory operations?       yes, currently we lack of old JIT support (I was thinking MCJIT 
will be the future, but from the mailinglist archive, it seems old JIT 
is still necessary), SIMD intrinsic support etc. all these will be 
supported next.

       As some of the llvm modules are in active development, for 
example MC Layer, we want to return code to community repository first, 
so that it will be easy to keep pace with llvm main
tree.>
> Will you be able to setup a buildbot on this architecture? If so, can it be
connected to the public system?       yes, I guess it's OK to setup a tilegx buildbot with connection 
to public system. I will confirm this with the company.>
> On the patch itself:
>
>   1. There are still a few places where there is commented-out code or #if
0 blocks; these should be removed (or replaced with real comments as
appropriate).
       thanks, I will fix these things.>
>   2. There are no regression tests -- using the test-suite is obviously
useful, but targeted regression tests are essential.
        yes, regression tests will be added later.>
> You say that there are unexpected failures in the regression tests and in
the test suite. Do you understand these?        yes, I have done investigation on these failures.

        regression (44 failures)
        ==          20: caused JITTests failures, we lack old jit support
          2:
             MCJIT/test-common-symbols-remote.ll
             MCJIT/test-fp-no-external-funcs-remote.ll

         the other 20 are mostly under Clang:: Tooling (these testcases 
seems to be added in this week) & some debuginfo testcases,  I will 
clean up them later.


        test-suite (17 failures)
        =====            1 of them are compile stage failures
             ==                   MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4
                   the reason is tilegx do not support some c99 float 
rounding & exceptions
                   we lack the support of some flag like FE_DIVBYZERO 
etc, for fegetexceptflag.

            16 of them are runtime failures.
             ==                   actually, I compare all these failures with
our gcc
output, it's the same.
                   nearly all of them are caused by float point 
precision issue, for example,

  MultiSource/Applications/sqlite3/

  ...
  6|496148.333333333
-6|496234.333333333  <=== expected output & x86_64 result
+6|496234.333333334  <=== tilegx gcc/llvm result
  8|496373.0
  8|496448.375
  1|496587.0
-6|496647.333333333
+6|496647.333333334
  ...

---
Regards,
Jiong
>
>   -Hal
>
>> TILE-Gx is a VLIW architecture with 64-bit registers, 64-bit address
>> space,
>> and 64-bit instructions. TILE-Gx has load-store architecture ISAs.
>>
>> More information on the architectures is available at
>> http://www.tilera.com/scm/docs/index.html.
>>
>> the attached patches contains the following main features for tilegx
>> backend:
>>
>> 1. general function.
>> 2. PIC/TLS/JumpTable.
>> 3. Instructoin Bundling for VLIW.
>> 4. Basic support for Asm Parser.
>> 5. MC Layer (aware of VLIW), MCJIT support.
>>
>> I've run the regression test and standalone test-suite natively on
>> TILE-Gx silicon. The
>> test results are:
>>
>> regression
>> ---
>> Expected Passes : 13218
>> Expected Failures : 78
>> Unsupported Tests : 68
>> Unexpected Failures: 44
>>
>> test-suite
>> ---
>> Expected Passes : 949
>> Unexpected Failures: 17
>>
>> the llvm patch is against:
>>
>> commit 5e812139690ce077d568ef6559992b2cf74eb536
>> Author: Evgeniy Stepanov <eugeni.stepanov at gmail.com>
>> Date: Thu Feb 28 11:25:14 2013 +0000
>>
>> [msan] Implement sanitize_memory attribute.
>>
>> the clang patch is against:
>>
>> commit a4d4621b206f941cc58d9d0bc7c67a8e705c9d49
>> Author: Daniel Jasper <djasper at google.com>
>> Date: Thu Feb 28 11:05:57 2013 +0000
>>
>> Improve formatting of #defines.
>>
>> the test-suite patch is against:
>>
>> commit 8c1ab3b660e67b74421d657408167b1345188f8d
>> Author: Duncan Sands <baldrick at free.fr>
>> Date: Sun Feb 17 15:21:11 2013 +0000
>>
>> Use LLVMCC_EMITIR_FLAG rather than -emit-llvm
>>
>>
>> please review, looking forward to your feedback.
>>
>> thanks.
>>
>> ---
>> Regards,
>> Jiong
>> Tilera Corporation.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>

-- 
Regards,
Jiong. Wang
Tilera Corporation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130301/602037c8/attachment.html>

Jiong Wang

2013-Mar-01 08:50 UTC

head link

[LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

On 03/01/2013 03:34 PM, Jiong Wang wrote:> On 03/01/2013 02:57 PM, Hal Finkel wrote:
> Hi Hal,
>
>   thanks for feedback.
>> Jiong, I am happy to see the Tile backend being offered for upstream 
>> inclusion. Among other things, in the long run, this may help inform 
>> and motivate many-core capabilities in LLVM.
>>
>> First, can you elaborate on the future maintenance and development 
>> plans for the target code? Do you plan to add SIMD support? Atomic 
>> memory operations?
>       yes, currently we lack of old JIT support (I was thinking MCJIT 
> will be the future, but from the mailinglist archive, it seems old JIT 
> is still necessary), SIMD intrinsic support etc. all these will be 
> supported next.
         ===>  besides these, for the next step, we will support more 
peephole optimizations, optimize float operation using  special hardware 
instruction, implement a VLIW aware MI schduler etc, to improve 
instruction level parallelism.
                    And I guess it will be interesting for how to 
support higher level parallelism using TileGX's 72 core
:)>
>       As some of the llvm modules are in active development, for 
> example MC Layer, we want to return code to community repository 
> first, so that it will be easy to keep pace with llvm main tree.
>>
>> Will you be able to setup a buildbot on this architecture? If so, can 
>> it be connected to the public system?
>       yes, I guess it's OK to setup a tilegx buildbot with connection 
> to public system. I will confirm this with the company.
>>
>> On the patch itself:
>>
>>   1. There are still a few places where there is commented-out code 
>> or #if 0 blocks; these should be removed (or replaced with real 
>> comments as appropriate).
>       thanks, I will fix these things.
>>
>>   2. There are no regression tests -- using the test-suite is 
>> obviously useful, but targeted regression tests are essential.
>        yes, regression tests will be added later.
>>
>> You say that there are unexpected failures in the regression tests 
>> and in the test suite. Do you understand these?
>        yes, I have done investigation on these failures.
>
>        regression (44 failures)
>        ==>          20: caused JITTests failures, we lack old jit
support
>          2:
>             MCJIT/test-common-symbols-remote.ll
>             MCJIT/test-fp-no-external-funcs-remote.ll
>
>         the other 20 are mostly under Clang:: Tooling (these testcases 
> seems to be added in this week) & some debuginfo testcases,  I will 
> clean up them later.
>
>
>        test-suite (17 failures)
>        =====>            1 of them are compile stage failures
>             ==>                  
MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4
>                   the reason is tilegx do not support some c99 float 
> rounding & exceptions
>                   we lack the support of some flag like FE_DIVBYZERO 
> etc, for fegetexceptflag.
>
>            16 of them are runtime failures.
>             ==>                   actually, I compare all these failures
with our gcc
> output, it's the same.
>                   nearly all of them are caused by float point 
> precision issue, for example,
>
>  MultiSource/Applications/sqlite3/
>
>  ...
>  6|496148.333333333
> -6|496234.333333333  <=== expected output & x86_64 result
> +6|496234.333333334  <=== tilegx gcc/llvm result
>  8|496373.0
>  8|496448.375
>  1|496587.0
> -6|496647.333333333
> +6|496647.333333334
>  ...
>
> ---
> Regards,
> Jiong
>
>>
>>   -Hal
>>
>>> TILE-Gx is a VLIW architecture with 64-bit registers, 64-bit
address
>>> space,
>>> and 64-bit instructions. TILE-Gx has load-store architecture ISAs.
>>>
>>> More information on the architectures is available at
>>> http://www.tilera.com/scm/docs/index.html.
>>>
>>> the attached patches contains the following main features for
tilegx
>>> backend:
>>>
>>> 1. general function.
>>> 2. PIC/TLS/JumpTable.
>>> 3. Instructoin Bundling for VLIW.
>>> 4. Basic support for Asm Parser.
>>> 5. MC Layer (aware of VLIW), MCJIT support.
>>>
>>> I've run the regression test and standalone test-suite natively
on
>>> TILE-Gx silicon. The
>>> test results are:
>>>
>>> regression
>>> ---
>>> Expected Passes : 13218
>>> Expected Failures : 78
>>> Unsupported Tests : 68
>>> Unexpected Failures: 44
>>>
>>> test-suite
>>> ---
>>> Expected Passes : 949
>>> Unexpected Failures: 17
>>>
>>> the llvm patch is against:
>>>
>>> commit 5e812139690ce077d568ef6559992b2cf74eb536
>>> Author: Evgeniy Stepanov <eugeni.stepanov at gmail.com>
>>> Date: Thu Feb 28 11:25:14 2013 +0000
>>>
>>> [msan] Implement sanitize_memory attribute.
>>>
>>> the clang patch is against:
>>>
>>> commit a4d4621b206f941cc58d9d0bc7c67a8e705c9d49
>>> Author: Daniel Jasper <djasper at google.com>
>>> Date: Thu Feb 28 11:05:57 2013 +0000
>>>
>>> Improve formatting of #defines.
>>>
>>> the test-suite patch is against:
>>>
>>> commit 8c1ab3b660e67b74421d657408167b1345188f8d
>>> Author: Duncan Sands <baldrick at free.fr>
>>> Date: Sun Feb 17 15:21:11 2013 +0000
>>>
>>> Use LLVMCC_EMITIR_FLAG rather than -emit-llvm
>>>
>>>
>>> please review, looking forward to your feedback.
>>>
>>> thanks.
>>>
>>> ---
>>> Regards,
>>> Jiong
>>> Tilera Corporation.
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>
>

-- 
Regards,
Jiong. Wang
Tilera Corporation.

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

Hal Finkel

2013-Mar-01 14:42 UTC

head link

[LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

----- Original Message -----> From: "Jiong Wang" <jiwang at tilera.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "LLVM Developers Mailing List" <llvmdev at
cs.uiuc.edu>, cfe-dev at cs.uiuc.edu
> Sent: Friday, March 1, 2013 1:34:15 AM
> Subject: Re: [LLVMdev] RFC: TileGX,	a new backend for Tilera's many
core processor
> 
> 
> On 03/01/2013 02:57 PM, Hal Finkel wrote:
> Hi Hal,
> 
> thanks for feedback.
> 
> 
> Jiong, I am happy to see the Tile backend being offered for upstream
> inclusion. Among other things, in the long run, this may help inform
> and motivate many-core capabilities in LLVM.
> 
> First, can you elaborate on the future maintenance and development
> plans for the target code? Do you plan to add SIMD support? Atomic
> memory operations? yes, currently we lack of old JIT support (I was
> thinking MCJIT will be the future, but from the mailinglist archive,
> it seems old JIT is still necessary), SIMD intrinsic support etc.
> all these will be supported next.
> 
> As some of the llvm modules are in active development, for example MC
> Layer, we want to return code to community repository first, so that
> it will be easy to keep pace with llvm main tree.
I think this makes sense; but my impression is that the community will want a
clear idea that this will be maintained and improved for the foreseeable future.
> 
> 
> Will you be able to setup a buildbot on this architecture? If so, can
> it be connected to the public system? yes, I guess it's OK to setup
> a tilegx buildbot with connection to public system. I will confirm
> this with the company.
> 
> 
> On the patch itself:
> 
>  1. There are still a few places where there is commented-out code or
>  #if 0 blocks; these should be removed (or replaced with real
>  comments as appropriate). thanks, I will fix these things.
> 
> 
> 2. There are no regression tests -- using the test-suite is obviously
> useful, but targeted regression tests are essential. yes, regression
> tests will be added later.
I don't speak for everybody, but I'm pretty sure that you won't get
an okay to commit this upstream without regression tests. We need a good degree
of coverage in test/CodeGen/Tile (you can probably look at one of the other
more-recent targets, like AArch64, to get an idea of what is required).

 -Hal
> 
> 
> You say that there are unexpected failures in the regression tests
> and in the test suite. Do you understand these? yes, I have done
> investigation on these failures.
> 
> regression (44 failures)
> ==> 20: caused JITTests failures, we lack old jit support
> 2:
> MCJIT/test-common-symbols-remote.ll
> MCJIT/test-fp-no-external-funcs-remote.ll
> 
> the other 20 are mostly under Clang:: Tooling (these testcases seems
> to be added in this week) & some debuginfo testcases, I will clean
> up them later.
> 
> 
> test-suite (17 failures)
> =====> 1 of them are compile stage failures
> ==> MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4
> the reason is tilegx do not support some c99 float rounding &
> exceptions
> we lack the support of some flag like FE_DIVBYZERO etc, for
> fegetexceptflag.
> 
> 16 of them are runtime failures.
> ==> actually, I compare all these failures with our gcc output, it's
the
> same.
> nearly all of them are caused by float point precision issue, for
> example,
> 
> MultiSource/Applications/sqlite3/
> ...
>  6|496148.333333333
> -6|496234.333333333  <=== expected output & x86_64 result
> +6|496234.333333334  <=== tilegx gcc/llvm result
>  8|496373.0
>  8|496448.375
>  1|496587.0
> -6|496647.333333333
> +6|496647.333333334
>  ...
> 
> ---
> Regards,
> Jiong
> 
> -Hal
> 
> TILE-Gx is a VLIW architecture with 64-bit registers, 64-bit address
> space,
> and 64-bit instructions. TILE-Gx has load-store architecture ISAs.
> 
> More information on the architectures is available at
> http://www.tilera.com/scm/docs/index.html .
> 
> the attached patches contains the following main features for tilegx
> backend:
> 
> 1. general function.
> 2. PIC/TLS/JumpTable.
> 3. Instructoin Bundling for VLIW.
> 4. Basic support for Asm Parser.
> 5. MC Layer (aware of VLIW), MCJIT support.
> 
> I've run the regression test and standalone test-suite natively on
> TILE-Gx silicon. The
> test results are:
> 
> regression
> ---
> Expected Passes : 13218
> Expected Failures : 78
> Unsupported Tests : 68
> Unexpected Failures: 44
> 
> test-suite
> ---
> Expected Passes : 949
> Unexpected Failures: 17
> 
> the llvm patch is against:
> 
> commit 5e812139690ce077d568ef6559992b2cf74eb536
> Author: Evgeniy Stepanov <eugeni.stepanov at gmail.com> Date: Thu Feb
28
> 11:25:14 2013 +0000
> 
> [msan] Implement sanitize_memory attribute.
> 
> the clang patch is against:
> 
> commit a4d4621b206f941cc58d9d0bc7c67a8e705c9d49
> Author: Daniel Jasper <djasper at google.com> Date: Thu Feb 28
11:05:57
> 2013 +0000
> 
> Improve formatting of #defines.
> 
> the test-suite patch is against:
> 
> commit 8c1ab3b660e67b74421d657408167b1345188f8d
> Author: Duncan Sands <baldrick at free.fr> Date: Sun Feb 17 15:21:11
> 2013 +0000
> 
> Use LLVMCC_EMITIR_FLAG rather than -emit-llvm
> 
> 
> please review, looking forward to your feedback.
> 
> thanks.
> 
> ---
> Regards,
> Jiong
> Tilera Corporation.
> 
> _______________________________________________
> LLVM Developers mailing list LLVMdev at cs.uiuc.edu
> http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> --
> Regards,
> Jiong. Wang
> Tilera Corporation.

Jiong Wang

2013-Mar-01 14:52 UTC

head link

[LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

On 03/01/2013 10:42 PM, Hal Finkel wrote:>
> As some of the llvm modules are in active development, for example MC
> Layer, we want to return code to community repository first, so that
> it will be easy to keep pace with llvm main tree.
> I think this makes sense; but my impression is that the community will want
a clear idea that this will be maintained and improved for the foreseeable
future.      Hi Hal,

        sure, tilegx will be actively maintained &
improved.>>
>>
>> 2. There are no regression tests -- using the test-suite is obviously
>> useful, but targeted regression tests are essential. yes, regression
>> tests will be added later.
> I don't speak for everybody, but I'm pretty sure that you won't
get an okay to commit this upstream without regression tests. We need a good
degree of coverage in test/CodeGen/Tile (you can probably look at one of the
other more-recent targets, like AArch64, to get an idea of what is required).        thanks for pointting this out, I will add regression tests, then 
re-send the patch.
        before this, please feel free to give comments and suggestions 
on the existed patches.
---
Regards,
Jiong
>
>   -Hal
>
>>
>> You say that there are unexpected failures in the regression tests
>> and in the test suite. Do you understand these? yes, I have done
>> investigation on these failures.
>>
>> regression (44 failures)
>> ==>> 20: caused JITTests failures, we lack old jit support
>> 2:
>> MCJIT/test-common-symbols-remote.ll
>> MCJIT/test-fp-no-external-funcs-remote.ll
>>
>> the other 20 are mostly under Clang:: Tooling (these testcases seems
>> to be added in this week) & some debuginfo testcases, I will clean
>> up them later.
>>
>>
>> test-suite (17 failures)
>> =====>> 1 of them are compile stage failures
>> ==>> MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4
>> the reason is tilegx do not support some c99 float rounding &
>> exceptions
>> we lack the support of some flag like FE_DIVBYZERO etc, for
>> fegetexceptflag.
>>
>> 16 of them are runtime failures.
>> ==>> actually, I compare all these failures with our gcc output,
it's the
>> same.
>> nearly all of them are caused by float point precision issue, for
>> example,
>>
>> MultiSource/Applications/sqlite3/
>> ...
>>   6|496148.333333333
>> -6|496234.333333333  <=== expected output & x86_64 result
>> +6|496234.333333334  <=== tilegx gcc/llvm result
>>   8|496373.0
>>   8|496448.375
>>   1|496587.0
>> -6|496647.333333333
>> +6|496647.333333334
>>   ...
>>
>> ---
>> Regards,
>> Jiong
>>
>> -Hal
>>
>> TILE-Gx is a VLIW architecture with 64-bit registers, 64-bit address
>> space,
>> and 64-bit instructions. TILE-Gx has load-store architecture ISAs.
>>
>> More information on the architectures is available at
>> http://www.tilera.com/scm/docs/index.html .
>>
>> the attached patches contains the following main features for tilegx
>> backend:
>>
>> 1. general function.
>> 2. PIC/TLS/JumpTable.
>> 3. Instructoin Bundling for VLIW.
>> 4. Basic support for Asm Parser.
>> 5. MC Layer (aware of VLIW), MCJIT support.
>>
>> I've run the regression test and standalone test-suite natively on
>> TILE-Gx silicon. The
>> test results are:
>>
>> regression
>> ---
>> Expected Passes : 13218
>> Expected Failures : 78
>> Unsupported Tests : 68
>> Unexpected Failures: 44
>>
>> test-suite
>> ---
>> Expected Passes : 949
>> Unexpected Failures: 17
>>
>> the llvm patch is against:
>>
>> commit 5e812139690ce077d568ef6559992b2cf74eb536
>> Author: Evgeniy Stepanov <eugeni.stepanov at gmail.com> Date: Thu
Feb 28
>> 11:25:14 2013 +0000
>>
>> [msan] Implement sanitize_memory attribute.
>>
>> the clang patch is against:
>>
>> commit a4d4621b206f941cc58d9d0bc7c67a8e705c9d49
>> Author: Daniel Jasper <djasper at google.com> Date: Thu Feb 28
11:05:57
>> 2013 +0000
>>
>> Improve formatting of #defines.
>>
>> the test-suite patch is against:
>>
>> commit 8c1ab3b660e67b74421d657408167b1345188f8d
>> Author: Duncan Sands <baldrick at free.fr> Date: Sun Feb 17
15:21:11
>> 2013 +0000
>>
>> Use LLVMCC_EMITIR_FLAG rather than -emit-llvm
>>
>>
>> please review, looking forward to your feedback.
>>
>> thanks.
>>
>> ---
>> Regards,
>> Jiong
>> Tilera Corporation.
>>
>> _______________________________________________
>> LLVM Developers mailing list LLVMdev at cs.uiuc.edu
>> http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> --
>> Regards,
>> Jiong. Wang
>> Tilera Corporation.

-- 
Regards,
Jiong. Wang
Tilera Corporation.

Maybe Matching Threads

Search for more seemingly similar threads

llvm dev - Mar 2013 - [LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

[LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

[LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

[LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

[LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor

Maybe Matching Threads