[cfe-dev] Clang Intermediate Language

[dalas via cfe-dev]

What I have in my mind now is making the general Clang Intermediate 
Language(CIL).

When developing the Graphics card compiler based on LLVM Infrastructure, 
the optimization is fairly able on LLVM IR. But the problem is that most 
programmer are more familar to C-style code, not LLVM IR code. Also the 
fact that LLVM IR is more RISC-like format, there is some limitation to 
optimize which should be easy if the C/C++/Objective-C Intermediate 
Language is on clang.

Also what I have in mind is that most software patterns what most 
programmers want to optimize could be accomplished with just simplified 
Intermediate Language. With more C-like Intermediate Language, Specified 
Type-Statement on CIL for making software engineers able to easily 
optimize.

Though I have some concerns whether this higher-level IR which is more 
than LLVM IR could help optimize because it feels like duplicating the 
IR layer. Still doubt on whether this CIL is necessary for LLVM and 
Clang Infrastructure...


P.S. I wish there are some SPIR-V developers, and share their thought on 
the CIL.

On 19. 3. 3. 오전 2:10, Chris Lattner wrote:
> Hi Dalas,
>
> If you’re interested in swift specifically, it would make sense to ask 
> on the swift dev forum.  There is a lot of thought and time that went 
> into the design of SIL.
>
> More generally though, designing an IR like this is all about deciding 
> what level of representational abstraction you need, and this is 
> principally driven by what sorts of optimizations you want to do, and 
> what sort of software abstractions you want to simplify the lowering 
> from one level to another.
>
> In the case of the former, Clang has its “CFG” data structure, but 
> otherwise lacks a great representation for doing language-specific 
> dataflow based analysis and optimization.  We should be able to do 
> things like reference count optimizations of std::shared_ptr, should 
> be able to do advanced temporary-elimination optimizations which only 
> appear after inlining, should be able to do STL specific optimizations 
> like inserting “reserve” calls before loops that fill in data 
> structures, etc.
>
> On the lowering side of things, Clang’s CodeGen is monolithic, very 
> complicated, and includes lots of concerns mixed up.  The most 
> egregious of which is that the C/C++ ABI lowering stuff all happens in 
> one place, and there is no good way to factor this logic across the 
> LLVM ecosystem, other than generating C++ ASTs (or writing thunks in 
> C++ and compiling them to IR with clang, then inlining them, etc). 
>  This makes me really sad, and is something that a nice CIL could fix 
> or at least drastically improve.
>
> -Chris
>
>> On Mar 1, 2019, at 9:10 PM, ComputerFreak via cfe-dev 
>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>> Hi, folks. I am trying to understand the Intermediate Language in 
>> LLVM infrastructure.
>> But I cannot quite catch the grasp on how the Intermediate Language 
>> comes out.
>> I have some questions.
>>
>> 1. When developing the new Intermediate Language on Swift Programming 
>> Language, Have you started the development from the Parser, which is 
>> the beginning of the Compiler?
>>
>> 2. I searched some good Intermediate Language Projects, but couldn't 
>> find the good specification on IL-like projects. Would you able to 
>> give some lists of the good Intermediate Language Projects to get 
>> some brief Overview on this?
>>
>> Dalas
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190304/cbd935f9/attachment.html>