similar to: [LLVMdev] Access Softek looks for a project

Victor, please file a bug tracking the issue. We can put relevant information there including test cases used in the experiment etc. thanks, David On Wed, Feb 7, 2018 at 2:15 PM, Victor Leschuk <vleschuk at accesssoftek.com> wrote: > David, could you please clarify on which code did you gain 10% > improvement? I have run numerous tests with and w/o this option and it > looks

David, could you please clarify on which code did you gain 10% improvement? I have run numerous tests with and w/o this option and it looks like it has no effect on performance (I am talking of the old 2016 sample to be concrete). Maybe we could investigate it together? Just tell me where to start? On 02/07/2018 02:11 AM, Xinliang David Li wrote: > Victor, thanks for the experiment. > >

Just in case, a little update for this thread: There was a talk about "Protecting the code: Control Flow Enforcement Technology" during the recent llvm-dev meeting (https://llvm.org/devmtg/2018-04/talks.html#Talk_17). It was mentioned that some support is already implemented in LLVM. I did not have chance to look close on it though. Whole feature requires linker side support,

Victor, thanks for the experiment. My suspicion is it is due to the remaining issues with block layout -- especially with loop rotation (with PGO). Another problem is that tail dup is not happening after loop rotation which can limit the effectiveness of loop rotation. I tried the internal option -mllvm -force-precise-rotation-cost and there is about 10% speedup with -fprofile-use. This option

I expect r324738 will break on windows, as I mentioned I had to change CHECK: ./test.cpp:2:51 to CHECK: {\\|/}}test.cpp:2:51 ? Best regards, George | Developer | Access Softek, Inc ________________________________ От: David Blaikie <dblaikie at gmail.com> Отправлено: 9 февраля 2018 г. 18:35 Кому: George Rimar Копия: Robinson, Paul; llvm-dev at lists.llvm.org; Rafael Avila de Espindola

Hello David, thanks for detailed response! Do you have any tests that you use to measure the PGO effectiveness? I have tested clang version 6.0 with the same sample that Jie Chen used in 2016 and actually both frontend-based PGO and IR-based make code run slower, see the average time: clang++ -O3: 3.15 sec  clang++ -O3 and -fprofile-instr-use: 3.160 sec clang++ -O3 and -fprofile-use: 3.180 sec

I'd think we shouldn't do anything even for printing out a warning unless doing it is proved to be useful. On Wed, Mar 21, 2018 at 1:04 AM George Rimar <grimar at accesssoftek.com> wrote: > >I think we should wait until there is someone wanting to use these > features with lld. > > > >Cheers, > >Rafael > > Ok. Should we give an error when

Yeah, not sure either. The discussion about minimum compatibility usually comes down to what version is available on long-term OS releases. On Fri, Oct 2, 2020 at 12:38 PM George Rimar <grimar at accesssoftek.com> wrote: > > Is the code currently broken? > > > I don't know. Perhaps the code is fine, I did not try to compile LLVM > with all that compilers > >

> Le 2 oct. 2017 à 14:23, George Rimar <grimar at accesssoftek.com> a écrit : > > I think we can switch LLD either to "both" or probably to "gnu" by default as well. > Initial version of patch that changes default to "both" is here: D38407 > > Any thoughts ? > > Best regards, > George | Developer | Access Softek, Inc Hi, I

On Sat, Dec 16, 2017 at 11:40 AM George Rimar <grimar at accesssoftek.com> wrote: > Or following workflow: > > Split dwarf is used to make linker to proccess less, like relocations, > right ? > Partly, though the main motivation as far as I know, was to have to provide fewer bytes to the linker at all. That's why something like Apple's scheme (leave the debug info in

?But could not we for example do split dwarf, but for example do dedup of types ? I do not mean right now, but in a theory ? Best regards, George | Developer | Access Softek, Inc ________________________________ От: David Blaikie <dblaikie at gmail.com> Отправлено: 16 декабря 2017 г. 22:25 Кому: George Rimar Копия: Sean Silva; llvm-dev at lists.llvm.org; Rui Ueyama; Rafael Espindola Тема:

Hi Victor, The work Wolfgang is doing should get us to the "minimum syntactically correct DWARF v5" stage, which we really wanted to have for LLVM 7.0. That is, once we have .debug_rnglists and .debug_loclists done, you can ask for DWARF 5 and get something that conforms to the spec. However, it won't conform if you ask for type units (I'm working on that) or split DWARF. If

Ah, sorry, thanks - removed the "./" prefix entirely. Hope that works - if you happen to test it & find it doesn't, please let me know :) On Fri, Feb 9, 2018 at 7:38 AM George Rimar <grimar at accesssoftek.com> wrote: > I expect r324738 will break on windows, > > as I mentioned I had to change > > > CHECK: ./test.cpp:2:51 > > to > > CHECK:

On Fri, Oct 2, 2020 at 1:48 AM George Rimar <grimar at accesssoftek.com> wrote: > Thanks, David! > > > Few minor additions to the topic: > > > > I'm not sure which MSVC version on godbolt would be "MSVC 2017" that > the LLVM docs refer to > > > I've found that the minimal available version of MSVC on > godbolt is "WINE MSVC 2015:

On Sun, Feb 4, 2018 at 9:59 PM, Victor Leschuk <vleschuk at accesssoftek.com> wrote: > Hello David! > > I have recently started acquaintance with PGO in LLVM/clang and found > your e-mail thread: > http://lists.llvm.org/pipermail/llvm-dev/2016-May/099395.html . Here you > posted a nice list of optimizations that use profiling and of those > which could be using but

On Tue, Dec 11, 2012 at 11:40 AM, Galina Kistanova <gkistanova at accesssoftek.com> wrote: > Hello everyone, > > It might make sense to start from rebooting the buildmaster, just to make sure everything is all right on this end. > Yesterday I have tried to apply the latest changes from zorg and some of them are broken. > Theoretically, checkconfig shouldn't affect the

The problem remains after the buildmaster restart. Thanks Galina -----Original Message----- From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Tuesday, December 11, 2012 11:42 AM To: Galina Kistanova Cc: Duncan Sands; llvm-lab-wg at lists.minormatter.com; Galina Kistanova; llvmdev at cs.uiuc.edu Subject: Re: [llvm-lab-wg] FNT testers reporting success even though they failed On Tue,

On 11/12/12 23:16, Galina Kistanova wrote: > The problem remains after the buildmaster restart. The FNT builders are now all failing again, and the "report" is no longer empty. Does anyone know what fixed them? Ciao, Duncan. > > Thanks > > Galina > > > > -----Original Message----- > From: David Blaikie [mailto:dblaikie at gmail.com] > Sent: Tuesday,

This issue is back: FNT bots are reporting success in spite of tests failing, and the "report" text is empty again. Did someone change something? Ciao, Duncan. On 12/12/12 07:53, Duncan Sands wrote: > On 11/12/12 23:16, Galina Kistanova wrote: >> The problem remains after the buildmaster restart. > > The FNT builders are now all failing again, and the "report"

Thanks a lot for doing this. Having it automated an in a bot would be really nice. Cheers, Rafael George Rimar <grimar at accesssoftek.com> writes: > Hello guys, > > Today I tried to find the amount of LLD(elf) code covered by our test cases. So my aim was to run the LLD tests we have (run check-lld task) and find out which code was executed/covered and which was not. > >