[LLVMdev] Experimental Evaluation of the Schedulers in LLVM 3.3

[Andrew Trick]

> On Sep 5, 2014, at 8:16 AM, Arnold Schwaighofer <aschwaighofer at apple.com> 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 <atrick at apple.com <mailto: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/74fcabd1/attachment.html>