Page MenuHomePhabricator

maksfb (Maksim Panchenko)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 2 2015, 11:58 AM (320 w, 3 d)

Recent Activity

Thu, Sep 30

maksfb accepted D110886: Fix buildbots with shared lib builds.
Thu, Sep 30, 2:39 PM · Restricted Project

Wed, Sep 29

maksfb added a reviewer for D109412: [MC] Make MCDwarfLineStr class public: alexander-shaposhnikov.
Wed, Sep 29, 11:33 AM · Restricted Project

Tue, Sep 28

maksfb added a comment to D109412: [MC] Make MCDwarfLineStr class public.

Friendly ping.

Tue, Sep 28, 3:16 PM · Restricted Project

Sep 23 2021

maksfb added a comment to D109412: [MC] Make MCDwarfLineStr class public.

Thank you for adding the unit test, @rafaelauler! How does it look, @dblaikie?

Sep 23 2021, 12:04 PM · Restricted Project

Sep 9 2021

maksfb added a comment to D109412: [MC] Make MCDwarfLineStr class public.

 Note that MCDwarfLineTableHeader::Emit(), takes MCDwarfLineStr as an Optional<> parameter making it impossible to use the API if the class is not publicly defined.

Presumably you could still pass None to such an API? But yeah, couldn't use whatever functionality is exposed by passing a non-None value.

Sep 9 2021, 6:13 PM · Restricted Project
maksfb added a reviewer for D109412: [MC] Make MCDwarfLineStr class public: dblaikie.
Sep 9 2021, 5:03 PM · Restricted Project
maksfb added a comment to D109412: [MC] Make MCDwarfLineStr class public.

Friendly ping.

Sep 9 2021, 12:41 PM · Restricted Project
maksfb updated the diff for D109412: [MC] Make MCDwarfLineStr class public.
Sep 9 2021, 12:41 PM · Restricted Project

Sep 8 2021

maksfb added a comment to D109016: [llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations.

thanks for the quick fix; does this still need to be cherry-picked to release/13.x to close out https://bugs.llvm.org/show_bug.cgi?id=51684?

No problem. Good point, ideally it should be cherry-picked. Do you know what's the logistics for that?

I think https://llvm.org/docs/HowToReleaseLLVM.html#merge-requests is the official documentation, although I wouldn't be surprised if it's somewhat out-of-date, given it seems to be using SVN revision numbers! The essence though is that the release manager needs to be advised of which commit to cherry-pick.

Sep 8 2021, 1:51 PM · Restricted Project

Sep 7 2021

maksfb requested review of D109412: [MC] Make MCDwarfLineStr class public.
Sep 7 2021, 7:29 PM · Restricted Project
maksfb added a comment to D109016: [llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations.

thanks for the quick fix; does this still need to be cherry-picked to release/13.x to close out https://bugs.llvm.org/show_bug.cgi?id=51684?

Sep 7 2021, 4:11 PM · Restricted Project
maksfb committed rG6300e4ac5806: [llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations (authored by maksfb).
[llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations
Sep 7 2021, 11:29 AM
maksfb closed D109016: [llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations.
Sep 7 2021, 11:29 AM · Restricted Project
maksfb updated the diff for D109016: [llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations.

Add a leading nop for the test case.

Sep 7 2021, 11:01 AM · Restricted Project

Sep 2 2021

maksfb updated the diff for D109016: [llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations.

Address comments.

Sep 2 2021, 5:24 PM · Restricted Project

Aug 31 2021

maksfb updated the diff for D109016: [llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations.

Address comments.

Aug 31 2021, 2:52 PM · Restricted Project
maksfb requested review of D109016: [llvm-objdump] Fix 'llvm-objdump -dr' for executables with relocations.
Aug 31 2021, 12:15 PM · Restricted Project

Aug 30 2021

maksfb added a comment to D102296: [ELF] getRelocatedSection: remove the check for ET_REL object file.

llvm-objdump -dr seems to be broken when invoked on executables with relocations. Prior to this diff, llvm-objdump would simply not print relocations in executables while disassembling instructions, but now it's hitting the assertion since it started seeing the relocations. The problem is that relocation offsets are not adjusted wrt the section address.

Aug 30 2021, 8:31 PM · Restricted Project

May 14 2021

maksfb added inline comments to D102296: [ELF] getRelocatedSection: remove the check for ET_REL object file.
May 14 2021, 2:23 PM · Restricted Project

Mar 11 2021

maksfb committed rGdd832c7d3a7c: [RuntimeDyld] Speedup resolution of relocations to external symbols (authored by maksfb).
[RuntimeDyld] Speedup resolution of relocations to external symbols
Mar 11 2021, 5:12 PM
maksfb closed D97531: [RuntimeDyld] Speedup resolution of relocations to external symbols.
Mar 11 2021, 5:12 PM · Restricted Project
maksfb added reviewers for D97531: [RuntimeDyld] Speedup resolution of relocations to external symbols: MaskRay, dblaikie.
Mar 11 2021, 12:50 PM · Restricted Project

Mar 3 2021

maksfb added a comment to D97531: [RuntimeDyld] Speedup resolution of relocations to external symbols.

@lhames: does this diff make sense to you or I missed a way ExternalSymbolRelocations can get altered during the loop execution?

Mar 3 2021, 9:01 PM · Restricted Project

Feb 25 2021

maksfb requested review of D97531: [RuntimeDyld] Speedup resolution of relocations to external symbols.
Feb 25 2021, 11:59 PM · Restricted Project

Jul 5 2018

maksfb created D49001: [X86][Disassembler] Fix LOCK prefix disassembler support.
Jul 5 2018, 2:57 PM
maksfb created D49000: [DebugInfo] Change default value of FDEPointerEncoding.
Jul 5 2018, 2:46 PM

Oct 26 2016

maksfb added a comment to D25692: [AVX-512] Disassembler support for rounding control and SAE attribute..

I think the focus should be on fixing the state of LLVM's disassembler for AVX-512. While there could be issues with the encoder too, and it's important to find out if indeed the encoder has to be fixed, that has to be handled separately. This diff fixes multiple failures of LLVM disassembler while handling binaries with AVX-512, but it does not fix them all.

Oct 26 2016, 10:28 PM
maksfb added inline comments to D25692: [AVX-512] Disassembler support for rounding control and SAE attribute..
Oct 26 2016, 9:14 AM

Oct 25 2016

maksfb added inline comments to D25692: [AVX-512] Disassembler support for rounding control and SAE attribute..
Oct 25 2016, 3:16 PM
maksfb added a comment to D25692: [AVX-512] Disassembler support for rounding control and SAE attribute..

@delena : could you please take a look?

Oct 25 2016, 11:12 AM

Oct 17 2016

maksfb updated subscribers of D25692: [AVX-512] Disassembler support for rounding control and SAE attribute..
Oct 17 2016, 12:38 PM
maksfb retitled D25692: [AVX-512] Disassembler support for rounding control and SAE attribute. from to [AVX-512] Disassembler support for rounding control and SAE attribute..
Oct 17 2016, 12:26 PM

Sep 1 2016

maksfb added a comment to D24108: X86: Fold tail calls into conditional branches where possible (PR26302).

Don't know a lot about tail call handling, so the review with a grain of salt.
(The large amount of new instructions seems unfortunate, but, as above, I don't know enough about this to say whether this is avoidable...)

@hans: I think it is safe to do this optimization while optimizing for size. If you do it by default it could be a performance regression if you reverse direction of the conditional branch. That's what we found out while testing on a micro benchmark. I believe it's related to the way BTB works on Intel's CPUs. The problem is that unless you are doing LTO or work at the binary level, you don't always know the new direction of the branch.

Is there a reason to believe the change in direction will cause worse performance, systematically?
Or is this just a random effect on that particular microbenchmark, and we may gain performance in other cases?

Sep 1 2016, 4:55 PM
maksfb added a comment to D24108: X86: Fold tail calls into conditional branches where possible (PR26302).

@hans: I think it is safe to do this optimization while optimizing for size. If you do it by default it could be a performance regression if you reverse direction of the conditional branch. That's what we found out while testing on a micro benchmark. I believe it's related to the way BTB works on Intel's CPUs. The problem is that unless you are doing LTO or work at the binary level, you don't always know the new direction of the branch.

Sep 1 2016, 2:05 PM

Dec 9 2015

maksfb added a comment to D14676: [RuntimeDyld] Don't allocate unnecessary stub buffer space.

Sorry, for some reason phabricator emails escaped my inbox. The diff looks great!

Dec 9 2015, 11:01 AM

Nov 15 2015

maksfb added a comment to D14676: [RuntimeDyld] Don't allocate unnecessary stub buffer space.

Sanjoy, I'm not very familiar with all scenarios where stubs are used. Is it possible R_X86_64_PC32 relocation will need a stub?

Nov 15 2015, 11:23 AM

Nov 5 2015

maksfb retitled D14404: [RuntimeDyld] Add support for R_X86_64_PC8 relocation. from to [RuntimeDyld] Add support for R_X86_64_PC8 relocation..
Nov 5 2015, 4:06 PM

Sep 29 2015

maksfb updated the diff for D12681: Calling conventions for HHVM.

More feedback from Quentin.

Sep 29 2015, 12:57 PM
maksfb added a comment to D12681: Calling conventions for HHVM.

Thanks!

Sep 29 2015, 12:54 PM

Sep 28 2015

maksfb updated the diff for D12681: Calling conventions for HHVM.

Updated the patch based on Quentin's feedback, and rebased.

Sep 28 2015, 6:45 PM
maksfb added a comment to D12681: Calling conventions for HHVM.

Thanks for the review, Quentin!

Sep 28 2015, 5:02 PM

Sep 19 2015

maksfb updated the diff for D12681: Calling conventions for HHVM.

Updated the patch based on Philip's feedback.

Sep 19 2015, 11:46 AM

Sep 17 2015

maksfb added a comment to D12924: [PrologEpilogInserter] Minor refactoring..

I don't have commit access. Please land. Thx!

Sep 17 2015, 5:14 PM

Sep 16 2015

maksfb retitled D12924: [PrologEpilogInserter] Minor refactoring. from to [PrologEpilogInserter] Minor refactoring..
Sep 16 2015, 8:35 PM
maksfb added a reviewer for D12681: Calling conventions for HHVM: qcolombet.
Sep 16 2015, 8:35 PM
maksfb added a comment to D12681: Calling conventions for HHVM.

Thanks for the review. The stack skew is due to the deviation from x64 ABI and is related to the way we enter our translation cache which happens from a piece of assembly code. Typically on a function entry %rsp mod 16 == 8, for us it's %rsp mod 16 == 0. From LLVM point of view all the objects on the stack with alignment over 8 bytes have to be placed differently relative to %rsp. Also, if there happens to be a call to a regular function, we don't have to adjust %rsp when the stack frame is empty (on x64 you have to issue a dummy push or sub 8, %rsp). There's more info in inline comments on why we have to change the alignment rules for implementation.

Sep 16 2015, 7:40 PM

Sep 11 2015

maksfb added a comment to D12681: Calling conventions for HHVM.

Cool. Thanks.

Sep 11 2015, 12:38 PM

Sep 7 2015

maksfb updated the diff for D12681: Calling conventions for HHVM.

Restore the diff + suggestions by Sanjoy Das.

Sep 7 2015, 5:16 PM
maksfb updated the diff for D12681: Calling conventions for HHVM.
Sep 7 2015, 5:08 PM
maksfb added inline comments to D12681: Calling conventions for HHVM.
Sep 7 2015, 4:57 PM
maksfb retitled D12681: Calling conventions for HHVM from to Calling conventions for HHVM.
Sep 7 2015, 3:53 PM