similar to: [LLVMdev] Host compiler requirements: Dropping VS 2008, using C++11?

I'm in favor of dropping VS 2008 support (in fact, I thought we had already talked about doing that, but perhaps I am remembering incorrectly). I think C++11 support should be a separate discussion than dropping VS 2008 support because it's likely to be a bit more in-depth, but I'm in favor of it. ~Aaron On Sat, Jul 6, 2013 at 12:05 PM, Ahmed Bougacha <ahmed.bougacha at

Hello, I have just updated my svn copy of the llvm/clang repositories after quite a long time of inactivity, and found it not compiling on Windows with Visual Studio 2008. The incriminated file is: llvm/lib/MC/MCModule.cpp Where several calls to "std::lower_bound" are made, like: atom_iterator I = std::lower_bound(atom_begin(), atom_end(),

On Thu, Jul 4, 2013 at 12:48 AM, Benoit Perrot <benoit.noe.perrot at gmail.com>wrote: > Hello, > Hi Benoit, > I have just updated my svn copy of the llvm/clang repositories after quite > a long time of inactivity, and found it not compiling on Windows with > Visual Studio 2008. > > The incriminated file is: > > llvm/lib/MC/MCModule.cpp > > Where several

There is some historical precedence for fixing the problem with VS lower_bound by changing the LLVM source - when I first got LLVM to compile with Visual Studio, patches for unsymmetric operator < were accepted into the LLVM repo, and I believe it's been done several times after that as well. m. >From: Ahmed Bougacha >Sent: Friday, July 05, 2013 1:43 AM >To: Benoit Perrot

On Sat, Jul 6, 2013 at 9:59 AM, Aaron Ballman <aaron at aaronballman.com>wrote: > I'm in favor of dropping VS 2008 support (in fact, I thought we had > already talked about doing that, but perhaps I am remembering > incorrectly). > +1 -- we're good with dropping VS 2008, especially if we document it clearly in the release notes. I think C++11 support should be a

On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > Which brings us to my fallback proposal: what about disabling the > pass on darwin only? That's a decision for Jim/Evan. I'm ok if they are. > As for other targets, as a first step, making the pass run under -O3 > rather than -O1 is hopefully agreeable to everyone? Sounds reasonable.

I filed a couple more, in case they're actually different issues: - http://llvm.org/bugs/show_bug.cgi?id=22412 - http://llvm.org/bugs/show_bug.cgi?id=22413 And that's pretty much it for internal changes. I'm fine with flipping the switch; Quentin, are you? Also, just to have an idea, do you (or someone else!) plan to tackle these in the near future? -Ahmed On Thu, Jan 29, 2015 at

On Fri, Feb 27, 2015 at 2:01 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >> Which brings us to my fallback proposal: what about disabling the >> pass on darwin only? > > That's a decision for Jim/Evan. I'm ok if they are. Jim, thoughts? > >> As for other

Hi Ahmed, Did you run these experiments on a platform with a linker that makes use of the AArch64CollectLOH-pass-produced information? I'm guessing that the AArch64CollectLOH-pass information and a linker that makes use of that information could affect the profitability of the GlobalMerge pass? Thanks, Kristof > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu

Hi all, This is covered by (struct-path aware) TBAA, but BasicAA disagrees. See the attached testcase, where it prevents us from removing the redundant load. For arbitrary GEPs, we can't decide based on constant indices (because of e.g., &A[0][1] and &A[1][0], with *A a one-element array). BasicAA has some logic to "try to distinguish something like &A[i][1] against

> On Feb 27, 2015, at 2:15 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > > On Fri, Feb 27, 2015 at 2:01 PM, Renato Golin <renato.golin at linaro.org> wrote: >> On 27 February 2015 at 21:26, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: >>> Which brings us to my fallback proposal: what about disabling the >>> pass on darwin

On Wed, Mar 4, 2015 at 10:49 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> Yes, it is breaking during the legalize phase, depending on which >> TargetLowering callback method we use. For example, Custom will let it >> through to instructions selection, which it breaks at the

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

On Mon, Feb 2, 2015 at 10:59 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Feb 2, 2015 at 10:55 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: > >> Ah yes, the structs are what make it messy. >> >> How about the more useful constraint: >> - the (identical) base must point to a (possibly multidimensional) array >>

On Fri, Feb 27, 2015 at 3:51 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Fri, Feb 27, 2015 at 3:48 PM Ahmed Bougacha <ahmed.bougacha at gmail.com> > wrote: >> >> On Fri, Feb 27, 2015 at 3:13 PM, Quentin Colombet <qcolombet at apple.com> >> wrote: >> > To be precise, GlobalMerge is registered as a pre-ISel pass, but still

On Thu, Feb 26, 2015 at 2:33 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Hi Ahmed, > > Did you run these experiments on a platform with a linker that makes > use of the AArch64CollectLOH-pass-produced information? As Jim says, I'm on iOS, so yes. However, I'm mostly running tests with the pass disabled. > > I'm guessing that the

I may get one or two in the next month, but not more than that. Focused on the pass manager for now. If none get there first, I'll eventually circle back though, so they won't rot forever. On Jan 30, 2015 11:21 AM, "Ahmed Bougacha" <ahmed.bougacha at gmail.com> wrote: > I filed a couple more, in case they're actually different issues: > -

If I do T.getArch() == xxx TLI.setUnavailable(LibFunc::copysign) then this works at generating a call instead of not being able to select the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other LibFunc functions (such as floor, etc... these generate call just fine)? Thanks, Ryan On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

I (arduously) updated the docs, so VS 2008 support is gone now. I’m still curious about C++11 though! -- Ahmed