[cfe-dev] [llvm-dev] is LLVM IR suitable for your library Optimization?

[dalas via cfe-dev]

On 19. 3. 15. 오전 10:30, dalas wrote:
>
> Recent Projects many ML companies are trying on ML Library 
> Optimization is using LLVM Infrastructure by deploying their 
> customized LLVM IR nodes. Of course the main companies who are using 
> the nodes are from Chip companies who want to evolve ML Libraries for 
> their own domain-specific ABI. I also agree on some points you have in 
> mind that the LLVM IR is more leaned on hardware platform.
>
> I read Rust Intermediate Language, MIR, Documention which Rust 
> Compiler uses. Though I have to read more, but the optimization passes 
> they are using for Rust-specific features seem applicable to clang 
> also. (Or already adopted, sorry this portion is not what I haven't 
> analyzed. I'll do more on that) But when reading some documentation 
> and "Introducing MIR", some features are missing in LLVM IR types and 
> declarations typically goto attributes. The GCC Gimple has goto 
> attribute when managing the function, conditional branch etc. Probably 
> this might be the thing that LLVM IR might have to implement for 
> Library Optimization or Clang Intermediate Language can easily 
> implement in the future i hope. (still mysterious why this goto 
> keyword is missing in LLVM IR. I thought this goto attribute is more 
> easily to implement in RISC-like from than in C-like form....)
>
> I do think the Clang AST is handy and affordable to introduce new 
> Intermediate Language because Clang AST nodetypes are representative. 
> But the thing is that there is no good text-friendly and easy-to-read 
> Intermediate Language from Clang AST. Then would the Clang 
> Intermediate Language function as .ll format which represents the LLVM 
> bitcode on text format? or need to build the Clang Intermediate 
> Language format which is entirely departed from Clang AST?
>
>
> On 19. 3. 14. 오후 3:00, Chris Lattner wrote:
>> <moving cfe-dev to BCC to reduce crossposting>
>>
>> It is perfectly possible to do library level optimization on LLVM IR, if you library has very close to the C API.  LLVM has a bunch of stuff that does this, e.g. optimizations for strcat, strcmp, etc.
>>
>> That said, doing optimizations on high level language abstractions (e.g. std::vector or std::shared_pointer or Swift.Array) is probably *possible* but is not great, because much of the target-specific ABI details get lowered out into LLVM IR, which makes pattern matching on the IR target specific and fragile.
>>
>> Beyond that, optimizations on (for example) C++ types want to think about concepts like “copy constructors” language rules which aren’t preserved perfectly in LLVM IR.
>>
>> It is important to know that MLIR *is* a three address SSA IR like LLVM, it is just that the type system and operations are dialect defined instead of being hard coded.
>>
>> -Chris
>>
>>
>>
>>> On Mar 13, 2019, at 6:26 PM, dalas via llvm-dev<llvm-dev at lists.llvm.org>  wrote:
>>>
>>> Hi, One question got in my head recently from the slides "MLIR Primer : A Compiler Infrastructure for the End of Moore's Law"
>>>
>>> When trying to optimize the source code based on LLVM IR, Do the compiler developers and the SW Library developers feel enough to improve easily? Wouldn't it be hard for them to handle the Low-Level IR to optimize? This question kept in my mind because I can't catch the capability whether the LLVM IR is the best optimization Intermediate Language for Library Developer. Mostly the Library optimization is switching the Function, Function Parameters, Loop unrolling, etc. Does it really need to be done with SSA-form, RISC-like IR format to do all these? If there is a more C-like or C++-like IR, wouldn't it be more easy for Library Maintainer, such as ML Developer, Math Library, MultiThreading Library, etc?
>>>
>>>
>>> So I want to know what the practical developers feel about the current LLVM IR form to perform various optimization. Whether the RISC-like IR is better for the higher-level Optimization skills. Thanks for reading and answering the question. Peace Out!
>>>
>>>
>>> P.S. This question is not intended to discourage the LLVM IR development, but just pops up the talk on whether there could be more better solution on Clang Environment.
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev