[llvm-dev] Generating a loop from llvm bitcode

[Ejjeh, Adel via llvm-dev]

Thanks for your input David. I am aware of the concerns that you brought up, and I am aware about the issues of code duplication. I am willing to deal with duplication, but I need to have the proper loop structure. That’s why my main concern right now is to be able to identify the induction variable of the loop so that I can print out the “for …” statement. Even if I am only able to start out with basic loops. The main issue that I haven’t been able to find a straight-foward work around for is determining the loop exit condition, and that is mainly what I am trying to get direction for in my original question. It is unfortunate that the InductionDescriptor data structure stores everything you can think of about an induction variable, except it’s End value.

-Adel

> On Aug 7, 2018, at 1:18 PM, David Greene <dag at cray.com> wrote:
> 
> 
> "Ejjeh, Adel via llvm-dev" <llvm-dev at lists.llvm.org> writes:
> 
>> Hello 
>> 
>> I am developing a backend that generates OpenCL from llvm bitcode. I
>> start with a revived fork of the original LLVM C-Backend and have been
>> modifying it. 
> 
> How far do you intend to take this?  Reconstructing high-level control
> flow from a CFG is not possible in the general case without code
> duplication.  One can do quite a lot but the nature of low-level
> optimization means that at some point you'll likely need gotos, unless
> code expansion is not a concern.  And even then, the result won't look
> much like the source program (though you probably don't care).
> 
> Beyond that, reconstructing high-level characteristics of values
> (finding induction variables, getting proper array dimensions, etc.) is
> even more challenging.  One can't reconstruct original C struct types,
> for example, because many of them get merged into a single LLVM type.
> One might be able to do a bit better with TBAA but frontends would have
> to save a lot more information in the IR to allow general translation.
> 
> There are many things in LLVM that cannot be expressed in C.  C has no
> "shufflevector" operation, for example.  At best one can try to emit
> (non-portable) intrinsics which may or may not be acceptable.  Or emit
> some kind of awful loop, I guess.
> 
> The C backend was riddled with problems even beyond the above issues.
> If I were going to attempt something like this I don't think I'd start
> with that.
> 
> It's not a hopeless project as long as you manage your expectations.  :)
> 
>                          -David