Announcement

Collapse
No announcement yet.

AMD's GPU LLVM Backend Gains Support For Assembler & Inline Assembly

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD's GPU LLVM Backend Gains Support For Assembler & Inline Assembly

    Phoronix: AMD's GPU LLVM Backend Gains Support For Assembler & Inline Assembly

    Tom Stellard of AMD has landed initial support into the AMD GPU LLVM back-end for the assembler and supporting inline assembly...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by phoronix View Post
    Phoronix: AMD's GPU LLVM Backend Gains Support For Assembler & Inline Assembly

    Tom Stellard of AMD has landed initial support into the AMD GPU LLVM back-end for the assembler and supporting inline assembly...

    http://www.phoronix.com/scan.php?pag...M-Assembler-SI
    as horrible syntax as their normal inline assembly ?

    Comment


    • #3
      Originally posted by gens View Post
      as horrible syntax as their normal inline assembly ?
      http://nondot.org/sabre/LLVMNotes/InlineAsm.txt
      Well, do you have a better alternative? its the same syntax gcc uses, which is alot more flexible than say microsofts.

      Comment


      • #4
        Originally posted by discordian View Post
        Well, do you have a better alternative? its the same syntax gcc uses, which is alot more flexible than say microsofts.
        the only thing i see bad about microsoft (and borland and idk) inline asm is that you load variables into registers yourself
        but even that is not so bad since the cpu can just do a register rename
        it could, in theory ofc, even be done by just writing some thing like "eax=variable" to tell the compiler where to put it (like the gnu parameter passing does, but much less ugly)

        i never did much inline asm, is there anything else wrong with MS syntax ?

        Comment


        • #5
          Inline assembler, my development

          Oh yeahh! Inline assembler can allow to use real full set of features of Radeon GPU's.
          But I have some doubt. Will that Assembler for GCN be useful to developing greater projects?
          that Inline assembler will be working for Gallium Compute (but not with Catalyst).

          I can talk about my modest development which concerns that area:
          I am working on similar assembler (but standalone) which can works with Gallium and Catalyst .
          Maybe It will be publicly available in next month or summer (I don't know, because is still is in experimental stage).
          Actually, disassembler works fine (can disassemble Gallium and Catalyst OpenCL binaries) and
          AMD binary allow to generate binaries without any driver (standalone too).

          Comment


          • #6
            Originally posted by matszpk View Post
            Oh yeahh! Inline assembler can allow to use real full set of features of Radeon GPU's.
            But I have some doubt. Will that Assembler for GCN be useful to developing greater projects?
            that Inline assembler will be working for Gallium Compute (but not with Catalyst).

            I can talk about my modest development which concerns that area:
            I am working on similar assembler (but standalone) which can works with Gallium and Catalyst .
            Maybe It will be publicly available in next month or summer (I don't know, because is still is in experimental stage).
            Actually, disassembler works fine (can disassemble Gallium and Catalyst OpenCL binaries) and
            AMD binary allow to generate binaries without any driver (standalone too).
            I'm expecting this will be among the shared stuff for open and closed amdgpu stacks. Traditional Catalyst is most likely not worth that much thought

            Comment


            • #7
              Originally posted by gens View Post
              the only thing i see bad about microsoft (and borland and idk) inline asm is that you load variables into registers yourself
              but even that is not so bad since the cpu can just do a register rename
              it could, in theory ofc, even be done by just writing some thing like "eax=variable" to tell the compiler where to put it (like the gnu parameter passing does, but much less ugly)
              The gcc modell is more flexible as it uses wildcards for registers, and it translates well into the internal syntax-tree so inline asm blocks can flow through alot optimization stages. this allows to easily add simple functions that get perfectly inlined or dropped if the generated value is not used.
              The cost of learning the weird syntax is well spent, as once you wrote a set of small functions you can use them like builtins and dont have to write bigger blobs of (inline) assembly. Think more about extending the compiler (which is more complex) than blobs of assembly.

              Originally posted by gens View Post
              i never did much inline asm, is there anything else wrong with MS syntax ?
              It is very limited and the use is actually just for saving yourself function prolog/epilog and using C++ mangled Names vs writing plain assembly (AFAIR). But actually it was you stating that the gcc/llvm syntax is weird, which I might accept - but its not like there a alternatives with simpler syntax and similar complexity.

              Comment


              • #8
                Originally posted by discordian View Post
                The gcc modell is more flexible as it uses wildcards for registers, and it translates well into the internal syntax-tree so inline asm blocks can flow through alot optimization stages. this allows to easily add simple functions that get perfectly inlined or dropped if the generated value is not used.
                The cost of learning the weird syntax is well spent, as once you wrote a set of small functions you can use them like builtins and dont have to write bigger blobs of (inline) assembly. Think more about extending the compiler (which is more complex) than blobs of assembly.
                Bullshit. FASM (Flat Assembler) does several optimization passes and does not use the horrible AT&T syntax.

                Comment


                • #9
                  Irrelevant: what is the state of OpenCL with RadeonSI GPUs?

                  Comment


                  • #10
                    Originally posted by discordian View Post
                    The gcc modell is more flexible as it uses wildcards for registers, and it translates well into the internal syntax-tree so inline asm blocks can flow through alot optimization stages. this allows to easily add simple functions that get perfectly inlined or dropped if the generated value is not used.
                    The cost of learning the weird syntax is well spent, as once you wrote a set of small functions you can use them like builtins and dont have to write bigger blobs of (inline) assembly. Think more about extending the compiler (which is more complex) than blobs of assembly.
                    thx but no
                    nobody is going to write a C/asm hybrid program using inline, as just writing them separately then linking makes more sense in that case
                    inline is useful for things like vector processing where the compiler can't help you and some one-liners where you know something that the compiler doesn't
                    (or where a version of the compiler just f-s up for some reason, gcc has some funny cases)

                    i want the code i write to be used as is and i want it to be easy (and i like intel syntax, that is painful to do with gcc)



                    @ wargames
                    fasm does passes mostly on macros
                    it does not change any code you write (as the name says, it is a flat assembler)

                    Comment

                    Working...
                    X