[lldb-dev] [cfe-dev] [LLVMdev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk

[Aaron Ballman]

If we have no other major users who require VS 2012 support, I think
it's reasonable to officially switch now. We might want to wait for
3.6 to go out the door, just to reduce possible issues with porting
fixes, but that may be overly cautious.

~Aaron

On Wed, Jan 28, 2015 at 7:16 AM, Greg Bedwell <gregbedwell at gmail.com> wrote:
> This thread seems to have stalled again without resolution :).  Is there
> anything else left blocking this change?  We've had our PS4 toolchain builds
> switched over to VS2013 since I reported back in October without any issues.
>
> -Greg
>
> On 8 October 2014 at 18:35, Aaron Ballman <aaron at aaronballman.com> wrote:
>>
>> On Wed, Oct 8, 2014 at 12:17 PM, Greg Bedwell <gregbedwell at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > To follow up from Paul last week:
>> >
>> >> I'm expecting to have our internal builds switched over later this
>> >> week.  Our investigations have shown no problems.
>> >
>> > We've now updated our internal builds from 2012.4 (cl.exe 17.0.61030) to
>> > 2013.3 (cl.exe 18.00.30723).  Our automated testing over the weekend
>> > hasn't
>> > shown any correctness issues so we plan to continue using it now..
>> >
>> > From some of the stats I've collected it seems to be a worthwhile
>> > update.
>> > On my own machine, the time for a full rebuild from clean of ALL_BUILD
>> > (LLVM
>> > & Clang, Release + asserts + debug info, not using ninja) has improved
>> > by
>> > 20%.  Doing a like-for-like build of various benchmarks and games using
>> > clang built by VS2012 and VS2013, the clang build speed of a typical -O2
>> > -g
>> > build is somewhere between in the noise and 1% faster with VS2013.
>> > We've
>> > not yet observed any regressions in the speed of clang since upgrading.
>>
>> Great, thank you for the feedback!
>>
>> ~Aaron
>
>