- User Since
- Sep 2 2015, 11:58 AM (320 w, 3 d)
Thu, Sep 30
Wed, Sep 29
Tue, Sep 28
Sep 23 2021
Sep 9 2021
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 8 2021
Sep 7 2021
Add a leading nop for the test case.
Sep 2 2021
Aug 31 2021
Aug 30 2021
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.
May 14 2021
Mar 11 2021
Mar 3 2021
@lhames: does this diff make sense to you or I missed a way ExternalSymbolRelocations can get altered during the loop execution?
Feb 25 2021
Jul 5 2018
Oct 26 2016
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 25 2016
@delena : could you please take a look?
Oct 17 2016
Sep 1 2016
@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.
Dec 9 2015
Sorry, for some reason phabricator emails escaped my inbox. The diff looks great!
Nov 15 2015
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 5 2015
Sep 29 2015
More feedback from Quentin.
Sep 28 2015
Updated the patch based on Quentin's feedback, and rebased.
Thanks for the review, Quentin!
Sep 19 2015
Updated the patch based on Philip's feedback.
Sep 17 2015
I don't have commit access. Please land. Thx!
Sep 16 2015
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 11 2015
Sep 7 2015
Restore the diff + suggestions by Sanjoy Das.