search for: kristofer

Hi Kristof, > On May 25, 2017, at 2:09 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 24 May 2017, at 22:01, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Hi Kristof, >> >> Thanks for going back so fast! >> >>> On May 24, 2017, at 12:57 PM, Kristof Beyls

Hi Kristof, Thanks for going back so fast! > On May 24, 2017, at 12:57 PM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 24 May 2017, at 19:31, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Hi Kristof, >> >> Thanks for the measurements. >> >>> On May 24, 2017, at

Cool test :) It seems to work fine now, I don't see any new failures. IIUC, Kristof is also giving it another run. Cheers, Diana On 30 May 2017 at 22:57, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > > I’ve actually gone ahead and pushed the fix as I was able to produce a > small reproducer. > > This is r304244 > > Let me know if you encounter

Thanks Quentin, it's in progress now, I'll let you know how it goes. Cheers, Diana On 27 May 2017 at 03:36, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Kristof, > > I’ve pushed the localizer in r304051 and added it in the AArch64 O0 pipeline > in r304052. > > I let Diana investigate the seg fault she was seeing. > > @Diana, let me know if you need

Thanks Diana. That is indeed the assumption in the code and this is obviously wrong. Could you try the attached patch? (I haven’t even tried to compile it though) Cheers, -Quentin -------------- next part -------------- A non-text attachment was scrubbed... Name: localizer_tentative_fix.diff Type: application/octet-stream Size: 774 bytes Desc: not available URL:

Hi Kristof, Thanks for the measurements. > On May 24, 2017, at 6:00 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 23 May 2017, at 21:48, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Great! >> I thought I had to look at our pipeline at O0 to make sure optimized regalloc was

I don’t know of any further issues preventing us flipping the switch. At this point, I’d aim to flip the switch shortly after the creation of the 6.0.0 release branch, so that GlobalISel can harden a bit more enabled-by-default on trunk before it goes into an LLVM release (presumably 7.0.0 then). Thanks, Kristof > On 11 Dec 2017, at 17:08, Amara Emerson <aemerson at apple.com> wrote:

Hi Amara, My reasons for preferring the switch to happen after the release branch is based on the following observations: * As far as I can see, the projects and products following top-of-trunk tend to test much more extensively than the testing that happens for llvm.org<http://llvm.org> releases. I expect that the llvm.org<http://llvm.org> release testing won’t find potential

FYI all: the patch to enable it is available to review here: https://reviews.llvm.org/D41362 Thanks, Amara > On Dec 18, 2017, at 5:44 PM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Ok. We’ll look at what we can do to further stress test it in the next two months, additional suggestions from the community is welcome. Patch should be incoming to enable it

Hi Kristof, > On Apr 6, 2017, at 6:53 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > I've been digging a little bit deeper into the biggest performance regressions I've observed. > > What I've observed so far is: > * A lot of the biggest regressions are caused by unnecessarily moving floating point values through general purpose registers. I've

Hi, As it has been brought to my attention (by several parties), my current MB does not support VT-d. Since I don''t feel like purchasing a brand new system, I have searched for replacement MB-s that would fit into my existing uATX case, support my C2D CPU, and support at least 4x2GB ram. I have narrowed it down to the following four models: SUPERMICRO MBD-C2SBM-Q-O (Q35 chipset)

I've kicked off a run to compare "-O0 -g" versus "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2". I've selected the test-suite (albeit a version which is a couple of months old now) and a few short-running proprietary benchmarks to get data back quickly for an initial feel of where things are. This was running on Cortex-A57 AArch64 Linux. I saw one assertion

Hi Kristof, > On Apr 27, 2017, at 9:47 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Hi Quentin, > >> On 27 Apr 2017, at 00:48, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Hi Kristof, >> >>> On Apr 6, 2017, at 6:53 AM, Kristof Beyls <kristof.beyls at arm.com

On 18 Dec 2017, at 15:11, Amara Emerson <aemerson at apple.com<mailto:aemerson at apple.com>> wrote: On Dec 18, 2017, at 12:37 PM, Kristof Beyls <Kristof.Beyls at arm.com<mailto:Kristof.Beyls at arm.com>> wrote: Hi Amara, My reasons for preferring the switch to happen after the release branch is based on the following observations: * As far as I can see, the

Hi Kristof, Thanks for the updated numbers. > On May 31, 2017, at 7:45 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > >> >> On 31 May 2017, at 15:33, Diana Picus via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Cool test :) >> It seems to work fine now, I don't see any new failures.

Thanks for everyone giving their feedback! I saw pretty unanimous support for making -mcpu=generic the default and making -mcpu=generic schedule for an in-order CPU (Cortex-A8 in this case). I'll be making those changes shortly. I think the comments also make clear that it's less obvious whether we'd want -mcpu=native to become a default. It's probably good for some use cases, but

Great Quentin :). I've rerun the benchmarks comparing "-O0 -g" with "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2" on r302453, on AArch64 Cortex-A57. I indeed see almost no moves between GPR and FPR registers anymore (see details below for where I still see some). On geomean, I see 13% slow down (down from 17% on my previous run). On geomean, code size increase

Hi Quentin, On Tue, May 9, 2017 at 11:47 AM Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kristof, > > On May 9, 2017, at 3:41 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Great Quentin :). > > I've rerun the benchmarks comparing "-O0 -g" with "-O0 -g -mllvm > -global-isel -mllvm

On Thu, Apr 6, 2017 at 6:53 AM, Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I've been digging a little bit deeper into the biggest performance > regressions I've observed. > > What I've observed so far is: > * A lot of the biggest regressions are caused by unnecessarily moving > floating point values through general purpose registers.

I agree. Fixed in r237748. > On May 18, 2015, at 9:39 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > BTW – graphs like the one in attachment make me think that the LNT webUI should be showing > sample points by default instead of line graphs showing the minimum execution time > per build number. -------------- next part -------------- An HTML attachment was