[LLVMdev] Replacing a repetitive sequence of code with a loop

[Jonathan Roelofs]

On 6/3/15 4:26 PM, Frank Winter wrote:
> Ok, I will do some code reading;the reroll pass seems seems a good
> starting point.
>
> Renato, thanks for the hint that this is actually a loop pass! You're
> right that it's not always beneficial to roll things up. However in this
> particular case I don't worry about insisting to roll the code into a
> loop no matter what, i.e. not looking at heuristics etc. In the given
> application it will always be beneficial to roll it, this is an a priori
> assumption.(the example I posted is far smaller than what the
> application generates).
>
> All functions are generated at runtime with the builder (I am not coming

In that case, why not generate the loop yourself, instead of effectively 
performing a tonsillectomy from the wrong end?

> from a higher level language). Thus, I could embed the whole function in
> a loop with one iteration. I will probably try this, just to see what
> the reroll pass thinks about it.It will not solve everything. In real
> world code the code junks can become quite large (over 1000
> instructions) and I doubt that the reroller can handle that in it's
> current state.
>
> There's onemore thing.The resulting loops will have high iteration
> counts so that it would make sense to use all available CPU cores and
> distribute the iterations among them. As far as I can see it, threading
> must be taken care of 'outside of the LLVM IR', right?

Yes.


Jon

> Coming from the
> shown code, I would need a mechanism that modifies the starting and
> ending iteration of the loop and exposes those as arguments to the
> function, right? Aka,
>
> define void @vec_plus_vec(int %start_iteration, int %end_iteration,
> float* noalias %arg0, float* noalias %arg1, float* noalias %arg2) {
> entrypoint:
>
> and from the calling code (OMP probably) call the function from each
> thread with thread number matching start/stop parameters. Does anyone
> see any other solution to threading than this?
>
> Thanks,
> Frank
>
>
>
>
>
>
> On 06/03/2015 04:28 PM, Philip Reames wrote:
>>
>>
>> On 06/03/2015 01:13 PM, Renato Golin wrote:
>>> On 3 June 2015 at 19:57, Benjamin Kramer <benny.kra at gmail.com> wrote:
>>>> There's a loop reroll pass in LLVM trunk that should do exactly this
>>>> transformation.
>>> Though that's a loop pass (runOnLoop). What you could do is add a
>>> previous pass that would recognize the pattern and create a loop of 1
>>> iteration around the code and then run the reroll pass.
>> This sounds like we should need a separate pass which forms loops from
>> straight line code.  I would strongly suggest only forming loops when
>> you can find at least two iterations.  We can probably share most of
>> the code with the existing reroller, but the wrapper pass needs a
>> slightly different interface.
>>>
>>> If your pattern recognition is too good, it'll be redundant with the
>>> reroll pass, so I'm not sure how to do that without duplicating effort
>>> or destroying the IR (in case you're wrong). Adding 1-iteration loops
>>> to all functions won't work either. You'll have to balance the
>>> heuristics and make the pass optional, maybe with a pragma to help the
>>> compiler.
>>>
>>> cheers,
>>> --renato
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded