[LLVMdev] Eliminating gotos

[Benedict Gaster]

Hi Owen,

On 12/08/2008 16:52, "Owen Anderson" <resistor at mac.com> wrote:

> 
> SNIP
> 
> 
> I'm still not seeing how these two are any different.  You just replace the
> text of "if" with "br", and add the explicit target labels.  I should also
> point out that, in LLVM IR, the order the blocks are laid out in is not
> meaningful and could change, so representing them explicitly in the branch or
> "if" is a requirement.  Also, this ordering (and, indeed, the number and
> structure of basic blocks) is not guaranteed to be preserved into the
> Machine-level phase of code generation.
> 
> What I'm guessing you're getting at is that you need is to insert an end-if
> instruction at some point.  If this is the case, I don't think radically
> changing the LLVM IR is the path of least resistance.  What about having a
> Machine-level pass that enforces the ordering of blocks that you require and
> inserts the special instructions based on a high-level control flow
> reconstruction?  At the Machine-level, blocks are allowed to have multiple
> exits, so you could even implement the non-optimized case you gave first.
> Also, loop-structure analysis is available at the Machine level as well, which
> might help.
> 
[bg] Ok so I think I¹m starting to get it. You are correct in your assertion
that we need to insert the end-if instruction at some point and of course
else in the case of if-then-else constructs. But we also need to reconstruct
while-loops and it is unclear to me if you approach works for all cases of
gotos. The other concern here is that as we are targeting an instruction set
with virtual registers and register allocation and scheduling will be
performed by our assembler not within LLVM and so we are planning on
implementing a language style backend, similar in style to the MSIL backend,
and as such it is possible to use a  machine-level pass?
> 
> Seems like a lot simpler than massively altering the IR.
> 
>>  I agree that in some sense this is an argument over syntax but the issue for
>> us is that our ISA represents control flow using structured ops and so we
>> have no option but to re-write the code into this form or change the hardware
>> :-)!
>>  
> 
> I'm still not understanding your point here.  Even if LLVM spells it as "br",
> your target isel can match it to something spelled "if" with no problem.  See
> my suggestions above about inserting other special instructions and enforcing
> block ordering above.
>  
>>> 1. Extend LLVM with news ops to support if/loop.
>>> 2. Implement this with the insertion of intrinsics to represent high-level
>>> control-flow, introducing ³false² dependencies if necessary to allow
>>> optimizations to be applied without changing the semantics.
>>> 3. Implement some structure of to the side that represents this high-level
>>> flow. 
>>> 4.  
>>> 5.  
>>> 
>>>   Thoughts?
>>>  
> 
> I missed pointing this one out earlier, but you won't be able to do this with
> intrinsics, as block labels cannot be used as first class values, and so
> cannot be passed to a function call.  You'd actually have to add instructions
> to the IR, or come up with a string-based tagging scheme or something
> 
> Actually I was thinking something along the following lines:
> 
> OpenCL -> LLVM IR
> 2 SSA (mem2reg)
> LLVM optimizations
> 2 !SSA (phi2copy)
> Goto elimination with intrinsics
          Code gen (without register allocation and so on)
> 
> Where the goto elimination pass would generate something like:
> 
> define i32 @foo(i32 %x, i32 %y) {
> entry:    
>     %tobool    = icmp eq i32 %x, 0
> 
>     %dummy1  = call i1 %if i1 %tobool
>         %add = add i32 %x, 10
>         ret i32 %add
>     call void %endif i1 %dummy1
> 
>     %call = tail call i32 (...)* @bar( )
>     ret i32 %y
> }
> 
> I¹m not sure all this makes sense rather I¹m just thinking about the options
> and trying to develop a whole picture.
> 
> Ben
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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