search for: grimar

...kie <dblaikie at gmail.com> Отправлено: 16 декабря 2017 г. 22:25 Кому: George Rimar Копия: Sean Silva; llvm-dev at lists.llvm.org; Rui Ueyama; Rafael Espindola Тема: Re: [llvm-dev] [RFC] - Deduplication of debug information in linkers (LLD). On Sat, Dec 16, 2017 at 4:08 AM George Rimar <grimar at accesssoftek.com<mailto:grimar at accesssoftek.com>> wrote: >Wasn't our (lld/ELF's) position on debug info size that we should focus on providing a great split-dwarf workflow and not try go too far out of our way to deduplicate >or otherwise reduce debug info size inside...

...obinson, Paul; llvm-dev at lists.llvm.org; Rafael Avila de Espindola Тема: Re: [llvm-dev] Collecting address ranges in DWARFUnit::collectAddressRanges. Nah, doesn't look like it. Removed it (& the place I copied it from) in: r324738 Thanks! On Fri, Feb 9, 2018 at 7:28 AM George Rimar <grimar at accesssoftek.com<mailto:grimar at accesssoftek.com>> wrote: >Totally fair call, sorry it took me a while to come back around to this - added in r324702 Thanks ! Have a question: does it need "requres shell" ? I tried without and it worked for me under windows (had to chan...

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 .note.gnu.property section is in the > object?​ > > ​Best regards, >...

Nah, doesn't look like it. Removed it (& the place I copied it from) in: r324738 Thanks! On Fri, Feb 9, 2018 at 7:28 AM George Rimar <grimar at accesssoftek.com> wrote: > >Totally fair call, sorry it took me a while to come back around to this - > added in r324702 > > Thanks ! Have a question: does it need "requres shell" ? > I tried without and it worked for me under windows (had to change check > to...

?Hi, I found a new issue in lld (https://llvm.org/bugs/show_bug.cgi?id=26222), but after review of outputs internals still have no idea why that can happen. Do you have any thoughts about possible reasons of that ? I am going to continue investigating that tomorrow. Best regards, George. -------------- next part -------------- An HTML attachment was scrubbed... URL:

>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 .note.gnu.property section is in the object?? ?Best regards, George | Developer | Access Softek, Inc -------------- next part -------------- An HTML attachment was scrubbed... URL:

>Totally fair call, sorry it took me a while to come back around to this - added in r324702 Thanks ! Have a question: does it need "requres shell" ? I tried without and it worked for me under windows (had to change check to CHECK: .{{\\|/}}test.cpp:2:51 though). And I see nothing special probably that might require shell I think. We use cd/rm/cp in LLD testcases without requiring

> 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...

...: Fri Mar 11 12:19:05 2016 +0000 Compute value of local symbol with getVA. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263225 91177308-0d34-0410-b5e6-96231b3b80d8 r263227 ~2-3% slowdown for ScyllaDB commit 6b96b614d9e0232b106165255148af8909607ec1 Author: George Rimar <grimar at accesssoftek.com<mailto:grimar at accesssoftek.com>> Date: Fri Mar 11 12:57:52 2016 +0000 [ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263227 91177308-0d34-0410-b5e6-96231b3b80d8 r263228...

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...

Hi ! During linking LLD and other linkers builds a static hash table for dynamic symbols, so that in runtime dynamic linker can use this table and find symbols faster. --hash-style=style linker option is used to select the hash type: "Set the type of linker's hash table(s). style can be either "sysv" for classic ELF ".hash" section, "gnu" for new style GNU

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 > > that we claim as supported though. I just *guess* that we don't have a > bot that builds LL...

...t might be reasonable to allow > > DEFPAT[PATTERN1]: some > > DEFPAT[PATTERN2]: Define [[PATTERN1]] pattern here > > as the [[]] substitution can be done when the directive is read. > > > > My $.02, > > --paulr > > > > *From:* George Rimar <grimar at accesssoftek.com> > *Sent:* Friday, January 31, 2020 5:52 AM > *To:* Thomas Preud'homme <thomasp at graphcore.ai>; llvm-dev < > llvm-dev at lists.llvm.org>; Robinson, Paul <paul.robinson at sony.com>; > jh7370.2008 at my.bristol.ac.uk > *Subject:* Re: [RFC...

>Wasn't our (lld/ELF's) position on debug info size that we should focus on providing a great split-dwarf workflow and not try go too far out of our way to deduplicate >or otherwise reduce debug info size inside LLD? I recall there being some patches that made linking of large debug binaries like 1.5GB+ clang faster, but we decided to >reject those changes because split-dwarf was

I am very interested in reviving this. Did anyone get any further with these ideas? @Grimar: Did you do any profiling of the code? Were the slowdowns you were seeing fundamental (i.e. due to IO) or could a more optimal implementation reduce the slowdown? Did you do any end to end timings for compilation + link time? The same issues arise for all metadata sections: .eh_frame .deb...

...: Fri Mar 11 12:19:05 2016 +0000 Compute value of local symbol with getVA. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263225 91177308-0d34-0410-b5e6-96231b3b80d8 r263227 ~2-3% slowdown for ScyllaDB commit 6b96b614d9e0232b106165255148af8909607ec1 Author: George Rimar <grimar at accesssoftek.com> Date: Fri Mar 11 12:57:52 2016 +0000 [ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC. git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263227 91177308-0d34-0410-b5e6-96231b3b80d8 r263228 ~6-7% slowdown for ScyllaDB commit e5aedb...

On Wed, Mar 16, 2016 at 9:05 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 16 March 2016 at 01:34, George Rimar <grimar at accesssoftek.com> wrote: > > Slowdown by "[ELF] - Early continue in > InputSectionBase<ELFT>::relocate(). > > NFC." looks wierd for me. I do not see any reasons for any impact on > > perfomance by this change. > > > I think it is just because the...

> Is anyone already working on it? If not then I can take this task. Me - not. George.

...ge Rimar Копия: rafael at espindo.la; llvm-dev Тема: Re: [LLD/ELF] - Should we implement .note.gnu.property and/or Intel CET in LLD ? 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<mailto: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 .note.gnu.property section is in the object?? ?Best regards, George | De...

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: {\\|/}}test.cpp:2:51 > > ​ > Best regards, > George | Developer | Access Softek, Inc > -----------...