Re: Experimental Evaluation of the Schedulers in LLVM 3.3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Experimental Evaluation of the Schedulers in LLVM 3.3

Richard Bagley

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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Experimental Evaluation of the Schedulers in LLVM 3.3

Andrew Trick

On Aug 14, 2014, at 7:51 PM, Richard Bagley <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Experimental Evaluation of the Schedulers in LLVM 3.3

Arnold Schwaighofer-3
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 <[hidden email]> wrote:


On Aug 14, 2014, at 7:51 PM, Richard Bagley <[hidden email]> 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?


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Experimental Evaluation of the Schedulers in LLVM 3.3

Andrew Trick

On Sep 5, 2014, at 8:16 AM, Arnold Schwaighofer <[hidden email]> wrote:

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.

I completely agree. Back porting anything but the most trivial fix is extremely risky. Much more risky IMO than merging the latest code from trunk. I was assuming people already knew this but it’s worth restating. There’s no good way to develop on a branch.

-Andy

On Sep 4, 2014, at 11:58 PM, Andrew Trick <[hidden email]> wrote:


On Aug 14, 2014, at 7:51 PM, Richard Bagley <[hidden email]> 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?



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev