llvm dev - Aug 2014 - [LLVMdev] Experimental Evaluation of the Schedulers in LLVM 3.3

I am seeking advice.



In your estimation, how difficult would it be to retrofit LLVM

3.2 with this body of improvements to instruction scheduling (and

optionally, the loop vectorization as well).



Would you have any suggestions for how best this might be

achieved, i.e.  the scope of the code required? Has anyone

attempted this kind of retrofit?



Thanks,

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140814/fa7d9a32/attachment.html>

On Aug 14, 2014, at 7:51 PM, Richard Bagley <rickbagley at gmail.com>
wrote:
> I am seeking advice.
> 
>  
> In your estimation, how difficult would it be to retrofit LLVM
> 
> 3.2 with this body of improvements to instruction scheduling (and
> 
> optionally, the loop vectorization as well).
> 
By now you probably know the answer to this better than I do. But for the
record:
MI scheduling infrastructure was largely in place by the 3.2 release. Since then
there have been bug fixes, new heuristics, and more target hooks. Those
improvements would probably be possible to back port if you’re really into that
kind of thing.

I’m going to guess that loop vectorization would be harder to back port because
much more work has been done in the past 3 releases. However, it is mostly a
self-contained pass apart from the cost model, so might be possible, just a lot
harder.

-Andy
>  
> Would you have any suggestions for how best this might be
> 
> achieved, i.e.  the scope of the code required? Has anyone
> 
> attempted this kind of retrofit?
> 
>  
> Thanks,
> 
> Rick
> 
> _______________________________________________
> 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/20140904/5e4b0ae2/attachment.html>

Personally,  I don’t think these sort of back ports are a good idea. You are
exposing differently shaped IR to the rest of the compiler, making it likely
that you will expose many bugs in the rest of the compiler that (probably) would
have been fixed in the ToT compiler but not in the old version.

I think it would be possible to back port the loop vectorizer with some effort,
which means back porting the changes to TargetTransformInfo (with its
dependencies on TargetLowering). The other dependencies should not have changed
significantly - except maybe changes in names here and there. Changes to the
loop vectorizer often where followed by changes to native code generation. You
might run into issues with backends not supporting the vectorized IR well so
your cost estimates are going to be off …

While certainly possible, I would not recommend it.

> On Sep 4, 2014, at 11:58 PM, Andrew Trick <atrick at apple.com>
wrote:
> 
> 
> On Aug 14, 2014, at 7:51 PM, Richard Bagley <rickbagley at gmail.com
<mailto:rickbagley at gmail.com>> wrote:
> 
>> I am seeking advice.
>> 
>>  
>> In your estimation, how difficult would it be to retrofit LLVM
>> 
>> 3.2 with this body of improvements to instruction scheduling (and
>> 
>> optionally, the loop vectorization as well).
>> 
> By now you probably know the answer to this better than I do. But for the
record:
> MI scheduling infrastructure was largely in place by the 3.2 release. Since
then there have been bug fixes, new heuristics, and more target hooks. Those
improvements would probably be possible to back port if you’re really into that
kind of thing.
> 
> I’m going to guess that loop vectorization would be harder to back port
because much more work has been done in the past 3 releases. However, it is
mostly a self-contained pass apart from the cost model, so might be possible,
just a lot harder.
> 
> -Andy
> 
>>  
>> Would you have any suggestions for how best this might be
>> 
>> achieved, i.e.  the scope of the code required? Has anyone
>> 
>> attempted this kind of retrofit?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140905/9b3f4d4e/attachment.html>