Page MenuHomePhabricator

avl (Alexey Lapshin)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 17 2017, 6:34 AM (191 w, 6 d)

Recent Activity

Yesterday

avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

Perhaps using a different option name would be useful, if we had that choice, but we don't always, either because of compatibility with existing tools, or to avoid unnecessarily breaking people's existing build scripts that use llvm-objcopy.

Tue, Apr 20, 3:44 AM · Restricted Project
avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

I've not checked, but if memory serves me correctly, there are some options (--add-symbol, I think, at least) that are parsed differently depending on the file format. As such, we can't parse them upfront - if we did, one of the two parse*Config functions would fail. We'd only want that to happen if a user was providing both file formats and the option.

It seems the same problem might occur even with lazy parsing. What if we have an archive containing object files with different formats. We might not be able to specify "--add-symbol" option which would be successfully parsed for both of them:

Tue, Apr 20, 2:55 AM · Restricted Project

Mon, Apr 19

avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

What do you think?

Mon, Apr 19, 1:17 PM · Restricted Project

Wed, Apr 14

avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

ping. Colleagues, what is your opinion on the way how this refactoring should be done?

Wed, Apr 14, 5:06 AM · Restricted Project

Mon, Apr 12

avl added a comment to D98511: [llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile().

@manojgupta @cjdb Sorry for the inconvenience. Please check, whether the problem is really fixed on your side(The commit with the fix is https://reviews.llvm.org/rGee8a5e4bc2c986b8e6c07e81fb58dc1e5a5c2d17)

Mon, Apr 12, 10:39 AM · Restricted Project
avl committed rGee8a5e4bc2c9: Fix chrome os failure after 021de7cf80268091cf13485a538b611b37d0b33e. (authored by avl).
Fix chrome os failure after 021de7cf80268091cf13485a538b611b37d0b33e.
Mon, Apr 12, 5:32 AM
avl added a comment to D98511: [llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile().

yep, will fix or revert.

Mon, Apr 12, 2:30 AM · Restricted Project

Thu, Apr 8

avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

ping.

Thu, Apr 8, 2:28 AM · Restricted Project

Fri, Apr 2

avl updated the diff for D99055: [llvm-objcopy] Refactor CopyConfig structure..

The one more argument for design presented by this patch is that: it is assumed that part of the interface
would be moved into the future ObjCopy library. The part which would be moved is quite small and clear.
Second part would be left in the llvm-objcopy tool. If we do not like its implementation(ParsedMultiFormatConfig)
we still might be able to reimplement llvm-objcopy part using another approach, but the library interface
will remain the same. Currently, indeed, we do not have many cross-format bugs. But, when this code
would be done as a library then it becomes more possibilities to do such cross-format bugs.
So, it is generally helpful if the interface of the library would prevent cross-format bugs.
I refactored this patch so that it would be more clear which part is supposed to go into the library
and which part is supposed to be left inside llvm-objcopy:

Fri, Apr 2, 6:20 AM · Restricted Project

Thu, Apr 1

avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

So the general point of this change is that previously all the options were in one struct which meant that, say, the MachO implementation could accidentally end up using an ELF option value, etc? And this way the implementations can accept the common options (the base class) and their implementation-specific options?

Thu, Apr 1, 4:08 AM · Restricted Project

Wed, Mar 31

avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

So the general point of this change is that previously all the options were in one struct which meant that, say, the MachO implementation could accidentally end up using an ELF option value, etc? And this way the implementations can accept the common options (the base class) and their implementation-specific options?

Any sense of whether that sort of cross-use was/is a significant source of bugs, or whether it'd be OK to just have chunks of the config specify "these are for ELF", "these are for MachO", etc (just in comments, or perhaps using ELF/MachO as a prefix, or having them in an ELF/MachO/etc subobject - while still having them all together/without the ability to create a common-and-MachO-view, common-and-ELF-view, etc) - I guess this came out of discussions in other reviews around the "it is necessary to minimize internal dependencies."? Might be good to have more of that context here to motivate/explain the benefits.

Wed, Mar 31, 7:35 AM · Restricted Project

Tue, Mar 30

avl requested review of D99626: [llvm-objcopy] Unify format specific options check..
Tue, Mar 30, 4:00 PM · Restricted Project
avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

if all the config property access went through virtual functions then it could probably be done without virtual inheritance, but with virtual functions and maybe some CRTP mix-in kind of implementations, but that may not be any better

Tue, Mar 30, 7:50 AM · Restricted Project
avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

I do have some concerns about the multiple inheritance stuff going on, if I'm honest, as usually this is a design smell

Tue, Mar 30, 7:38 AM · Restricted Project

Mon, Mar 29

avl updated the diff for D85614: [TRE] Reland: allow TRE for non-capturing calls..

rebased. retested.

Mon, Mar 29, 7:43 AM · Restricted Project

Fri, Mar 26

avl retitled D99055: [llvm-objcopy] Refactor CopyConfig structure. from [llvm-objcopy][NFC] Refactor CopyConfig structure. to [llvm-objcopy] Refactor CopyConfig structure..
Fri, Mar 26, 4:55 AM · Restricted Project
avl retitled D99055: [llvm-objcopy] Refactor CopyConfig structure. from [llvm-objcopy][NFC] remove processing of ELF specific options from common CopyConfig structure. to [llvm-objcopy][NFC] Refactor CopyConfig structure..
Fri, Mar 26, 4:55 AM · Restricted Project
avl updated the diff for D99055: [llvm-objcopy] Refactor CopyConfig structure..

Changed a patch to solve following problems:

Fri, Mar 26, 4:51 AM · Restricted Project

Wed, Mar 24

avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

after some more thinking, it seems to me that nor this patch nor current llvm version is not a right solution.

Wed, Mar 24, 3:59 AM · Restricted Project

Tue, Mar 23

avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

Looking at the design for ELF parseable options more, I do not really understand why parsing of ELF options should be delayed. It seems that they might be set at the same time when all other options parsed(i.e. as it was before D67139):

Tue, Mar 23, 2:59 PM · Restricted Project
avl updated the summary of D99055: [llvm-objcopy] Refactor CopyConfig structure..
Tue, Mar 23, 3:17 AM · Restricted Project
avl updated the diff for D99055: [llvm-objcopy] Refactor CopyConfig structure..

addressed comments:

Tue, Mar 23, 3:10 AM · Restricted Project

Mar 22 2021

avl committed rG972b6a3a3471: [llvm-objcopy][Support] move writeToOutput helper function to Support. (authored by avl).
[llvm-objcopy][Support] move writeToOutput helper function to Support.
Mar 22 2021, 5:42 AM
avl closed D98426: [llvm-objcopy][Support] move writeToStream helper function to Support..
Mar 22 2021, 5:41 AM · Restricted Project
avl added a comment to D98426: [llvm-objcopy][Support] move writeToStream helper function to Support..

Thank you, for the review.

Mar 22 2021, 2:35 AM · Restricted Project
avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

As for the main part of this change, I think this is essentially trying to redo D67139, which had a lot of back and forth discussion on it. Apart from anything else, the *Objcopy.cpp files are not where to put command-line parsing logic, which was an item from that review. Please go over the comments from D67139, and make sure to take the points raised in the comments on board. Once you have done that, feel free to propose a new solution (which could be similar to this, or something else entirely), if you feel it is important.

Mar 22 2021, 2:31 AM · Restricted Project
avl added a comment to D99055: [llvm-objcopy] Refactor CopyConfig structure..

Could you do this in a separate patch upfront, please? As things stand, this patch is not NFC, because of this...! I have some concerns about the specific nature of the non-NFC part, which I'd like to comment on separately.

Mar 22 2021, 2:31 AM · Restricted Project

Mar 21 2021

avl requested review of D99055: [llvm-objcopy] Refactor CopyConfig structure..
Mar 21 2021, 11:40 PM · Restricted Project

Mar 19 2021

avl updated the diff for D98426: [llvm-objcopy][Support] move writeToStream helper function to Support..

addressed comments.

Mar 19 2021, 6:52 AM · Restricted Project
avl added a comment to D98426: [llvm-objcopy][Support] move writeToStream helper function to Support..

There is of course a completely different approach, which would avoid this issue, namely to change the function to just create and return the stream and then leave the clients to pass the stream to their write functions. If you decided to switch to this approach, you'd probably want a new stream class derived from raw_fd_ostream which does the tempfile stuff itself, in the constructor/destructor, so that clients don't need t worry about that logic.

Mar 19 2021, 3:36 AM · Restricted Project

Mar 18 2021

avl updated the diff for D98426: [llvm-objcopy][Support] move writeToStream helper function to Support..

addressed comments.

Mar 18 2021, 2:43 PM · Restricted Project
avl committed rGeb4c85e4501e: [llvm-objcopy][NFC][Wasm] Do not use internal buffer while writing into the… (authored by avl).
[llvm-objcopy][NFC][Wasm] Do not use internal buffer while writing into the…
Mar 18 2021, 6:07 AM
avl closed D95478: [llvm-objcopy][NFC][Wasm] Do not use internal buffer while writing into the output..
Mar 18 2021, 6:07 AM · Restricted Project
avl added a comment to D95478: [llvm-objcopy][NFC][Wasm] Do not use internal buffer while writing into the output..

thanks for reviewing.

Mar 18 2021, 6:04 AM · Restricted Project
avl committed rGf134a7158b1e: [llvm-objcopy] remove split dwo file creation from executeObjcopyOnBinary. (authored by avl).
[llvm-objcopy] remove split dwo file creation from executeObjcopyOnBinary.
Mar 18 2021, 3:47 AM
avl closed D98582: [llvm-objcopy][NFC] remove split dwo file creation from executeObjcopyOnBinary..
Mar 18 2021, 3:46 AM · Restricted Project
avl added a comment to D98582: [llvm-objcopy][NFC] remove split dwo file creation from executeObjcopyOnBinary..

Thank you for the review.

Mar 18 2021, 3:24 AM · Restricted Project

Mar 17 2021

avl updated the diff for D98582: [llvm-objcopy][NFC] remove split dwo file creation from executeObjcopyOnBinary..

addressed comments.

Mar 17 2021, 10:01 AM · Restricted Project
avl committed rG021de7cf8026: [llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile(). (authored by avl).
[llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile().
Mar 17 2021, 7:29 AM
avl closed D98511: [llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile().
Mar 17 2021, 7:29 AM · Restricted Project
avl added inline comments to D98582: [llvm-objcopy][NFC] remove split dwo file creation from executeObjcopyOnBinary..
Mar 17 2021, 5:51 AM · Restricted Project
avl added a comment to D98511: [llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile().

Thank you for the review.

Mar 17 2021, 3:09 AM · Restricted Project

Mar 13 2021

avl retitled D98582: [llvm-objcopy][NFC] remove split dwo file creation from executeObjcopyOnBinary. from [llvm-objcopy] remove split dwo file creation from executeObjcopyOnBinary. to [llvm-objcopy][NFC] remove split dwo file creation from executeObjcopyOnBinary..
Mar 13 2021, 2:16 PM · Restricted Project
avl updated the diff for D98582: [llvm-objcopy][NFC] remove split dwo file creation from executeObjcopyOnBinary..

fix a mistake.

Mar 13 2021, 2:15 PM · Restricted Project
avl requested review of D98582: [llvm-objcopy][NFC] remove split dwo file creation from executeObjcopyOnBinary..
Mar 13 2021, 8:37 AM · Restricted Project

Mar 12 2021

avl updated the diff for D98511: [llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile().

addressed comments(removed ownership keeping code from FileOutputBuffer).

Mar 12 2021, 1:38 PM · Restricted Project
avl added a comment to D98511: [llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile().

I'm not sure if this would be a big issue but restoreStatOnFile also runs on the split dwo file, and will keep its ownership with this change. I don't think GNU assembler does that currently.

Mar 12 2021, 11:36 AM · Restricted Project
avl requested review of D98511: [llvm-objcopy][NFC] Move ownership keeping code into restoreStatOnFile().
Mar 12 2021, 7:43 AM · Restricted Project
avl added a comment to D98426: [llvm-objcopy][Support] move writeToStream helper function to Support..

Thank you for the review!

Mar 12 2021, 2:10 AM · Restricted Project

Mar 11 2021

avl requested review of D98426: [llvm-objcopy][Support] move writeToStream helper function to Support..
Mar 11 2021, 7:09 AM · Restricted Project

Mar 10 2021

avl updated the diff for D95478: [llvm-objcopy][NFC][Wasm] Do not use internal buffer while writing into the output..

rebased.

Mar 10 2021, 9:59 PM · Restricted Project
avl committed rG4f16e177e104: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams. (authored by avl).
[llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams.
Mar 10 2021, 12:52 PM
avl closed D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..
Mar 10 2021, 12:52 PM · Restricted Project
avl added a comment to D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

The problem our downstream user has run into is seen only when using llvm-objcopy to copy archives, not regular objects, likely because it is only triggered by the writing via raw_fd_ostream, which is not done for regular object files. This change appears to extend the problem to object files too, if I'm not mistaken, hence my concern. However, if the issue is fixed, then it is not an issue either way.

Mar 10 2021, 2:51 AM · Restricted Project

Mar 8 2021

avl added a comment to D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

It might be worth trying to get somebody to confirm the discussed issue has been fixed. Perhaps worth asking on llvm-dev. A simple reproducible is to do something like "llvm-objcopy test.a path/on/shared/drive/test.a".

Mar 8 2021, 12:46 PM · Restricted Project

Mar 6 2021

avl committed rGcf7cdaff64fb: [X86][VARARG] Avoid spilling xmm registers for va_start. (authored by avl).
[X86][VARARG] Avoid spilling xmm registers for va_start.
Mar 6 2021, 4:30 AM
avl closed D80163: [X86][VARARG] Avoid spilling xmm registers for va_start..
Mar 6 2021, 4:30 AM · Restricted Project

Mar 5 2021

avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

That seems quite expensive :s

Mar 5 2021, 2:19 PM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

Yeah, having to keep the types in memory is the bit I'm getting at - but yes, it's not all CUs. If they're being unloaded/reloaded though, it might be less clear whether it's so costly to preserve the existing output behavior. Though I don't personally have a problem with creating a synthetic/arbitrary CU to put all the types in either. But other folks (Apple folks with a vested interest in the dsymutil behavior) might disagree.

Mar 5 2021, 1:40 PM · Restricted Project

Mar 4 2021

avl updated the diff for D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

adressed comments.

Mar 4 2021, 11:39 AM · Restricted Project
avl added a comment to D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

will address comments. as to checking the "Windows 10 VM running using Parallels on a Mac" configuration - unfortunately, I do not have that hardware/configuration. So I would not be able to check it in the nearest future.

Mar 4 2021, 7:57 AM · Restricted Project

Mar 3 2021

avl added a comment to D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

Sorry, I've been unwell, and not been able to look more at this yet.

Mar 3 2021, 4:45 AM · Restricted Project
avl added a comment to D80163: [X86][VARARG] Avoid spilling xmm registers for va_start..

@pengfei @craig.topper Thank you for the review.

Mar 3 2021, 2:54 AM · Restricted Project

Mar 2 2021

avl added a reviewer for D80163: [X86][VARARG] Avoid spilling xmm registers for va_start.: pengfei.
Mar 2 2021, 12:16 PM · Restricted Project
avl updated the diff for D80163: [X86][VARARG] Avoid spilling xmm registers for va_start..

updated the test.

Mar 2 2021, 10:50 AM · Restricted Project
avl added inline comments to D80163: [X86][VARARG] Avoid spilling xmm registers for va_start..
Mar 2 2021, 6:35 AM · Restricted Project
avl added a comment to D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

@rupprecht @rnk Do you have comments/objections for this refactoring?

Mar 2 2021, 5:37 AM · Restricted Project

Mar 1 2021

avl added a comment to D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

@jhenderson Hi James, Is it OK now?

Mar 1 2021, 12:53 AM · Restricted Project
avl added a comment to D80163: [X86][VARARG] Avoid spilling xmm registers for va_start..

@craig.topper Would you mind to take a look at this updated patch once more, please?

Mar 1 2021, 12:52 AM · Restricted Project

Feb 28 2021

avl updated the diff for D80163: [X86][VARARG] Avoid spilling xmm registers for va_start..

rebased.

Feb 28 2021, 1:06 PM · Restricted Project

Feb 27 2021

avl committed rGdf6fb4d392e5: [llvm] Add assertions for the smart pointers with the possibility to be null in… (authored by OikawaKirie).
[llvm] Add assertions for the smart pointers with the possibility to be null in…
Feb 27 2021, 3:32 AM
avl closed D97185: [llvm] Add assertions for the smart pointers with the possibility to be null in DWARFLinker::loadClangModule.
Feb 27 2021, 3:32 AM · Restricted Project

Feb 25 2021

avl updated the diff for D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

rebased. addressed comments.

Feb 25 2021, 11:43 AM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

Sounds like your proposal would require that too - or require reloading the CUs twice? I think either strategy (keeping them loaded, or reloading them) could be used for either of our proposed directions (creating a separate unit, or using the existing units)?

Feb 25 2021, 2:27 AM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

I agree with Fred in that it might be too expensive to keep all of the CUs around so that we can later copy type data out of them at the end into uniqued compile units.

Feb 25 2021, 1:34 AM · Restricted Project

Feb 24 2021

avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

How would you guarantee that the artificial CU is always emitted in the same order? It seems like you need to stash the types somewhere, then create a deterministic ordering and then emit it, but I don't remember whether that's doable with LLVM's DIEs (It's been a while since I touched this code).

Feb 24 2021, 9:40 AM · Restricted Project
avl added a comment to D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

Will address all comments. I have a two questions/comments inside...

Feb 24 2021, 9:15 AM · Restricted Project
avl resigned from D81389: dwarf::isCPlusPlus fails with user language.
Feb 24 2021, 7:13 AM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

One idea is for each type we want to unique, each CU as it is being parsed on its own thread creates a type map that maps "type compile unit path" (which is DW_AT_decl_file of that type) to a list of uniqued types with decl context info. This would allow all types with the same DW_AT_decl_file to be stored in the same type compile unit. As we emit the debug info for a normal compile unit, any type references are changed to be DW_AT_ref_addr references with values that will need to be fixed up. After all normal CUs have been emitted, combine all of the CU specific type maps together, and now emit the type compile units (carefully to include all needed children in each type to make the most complete version of the type possible and emit them) in a sorted order to allow determinism. Then we fix up all DW_AT_ref_addr references in the normal CUs to point to the one type definition from the type compile units.

Feb 24 2021, 5:37 AM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

Comparing your proposal - avoiding nondeterminism by sorting the types by name in the new type-holding CU, we could do something similar, but instead sorting the CUs a type appears in to pick which of those existing locations to be the canonical home. (or, indeed, could sort by the original linear visitation order)

Feb 24 2021, 5:04 AM · Restricted Project

Feb 23 2021

avl accepted D97185: [llvm] Add assertions for the smart pointers with the possibility to be null in DWARFLinker::loadClangModule.

LGTM.

Feb 23 2021, 2:06 PM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

I'm not sure why that would necessarily be better/faster - it'd still require two passes, right? One to collect the types, then another to emit the unit with the types and the units referencing that?

Feb 23 2021, 2:00 PM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..
In D96035#2582780, @avl wrote:

A non-deterministic behavior is probably not acceptable - it'd certainly be no good at Google if we ever wanted to use this for DWARF linking. Not sure how the Apple folks feel about it for classic dsymutil.

Yes, this would be a non-starter.

even if it IS deterministic in --num-threads=1, and is Not deterministic in multi-thread case?

Yes :)

Feb 23 2021, 12:11 PM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

A non-deterministic behavior is probably not acceptable - it'd certainly be no good at Google if we ever wanted to use this for DWARF linking. Not sure how the Apple folks feel about it for classic dsymutil.

Yes, this would be a non-starter.

Feb 23 2021, 11:59 AM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

The final .debug_str should only have one copy of a string. It should be possible to create individual string tables and merge them in the last loop you have that fixes up offsets right?

Feb 23 2021, 11:53 AM · Restricted Project
avl added a comment to D91693: [Support] Add reserve() method to the raw_ostream..

Thanks! updated test accordingly.

Feb 23 2021, 3:11 AM · Restricted Project
avl committed rG875b3b2cdda1: [Support] Add reserve() method to the raw_ostream. (authored by avl).
[Support] Add reserve() method to the raw_ostream.
Feb 23 2021, 3:07 AM
avl closed D91693: [Support] Add reserve() method to the raw_ostream..
Feb 23 2021, 3:07 AM · Restricted Project

Feb 22 2021

avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

yep. this implementation is non-deterministic.
I tried to preserve the current ODR algorithm(which relies on concrete type sequences).

Feb 22 2021, 11:12 AM · Restricted Project
avl updated the diff for D91693: [Support] Add reserve() method to the raw_ostream..

change reserve() to reserveExtraSpace(). That allows pre-allocating
the internal stream buffers without knowing its current size.

Feb 22 2021, 10:34 AM · Restricted Project
avl added a comment to D96035: [WIP][dsymutil][DWARFlinker] implement separate multi-thread processing for compile units..

What do you think of this patch? Is it OK in general and Is it worth to divide it into smaller patches and integrate?

Feb 22 2021, 9:55 AM · Restricted Project
avl added a comment to D85614: [TRE] Reland: allow TRE for non-capturing calls..

ping.

Feb 22 2021, 9:52 AM · Restricted Project
avl updated the diff for D80163: [X86][VARARG] Avoid spilling xmm registers for va_start..

moved control-flow expansion for VASTART_SAVE_XMM_REGS until after regalloc.

Feb 22 2021, 12:51 AM · Restricted Project

Feb 19 2021

avl added inline comments to D91693: [Support] Add reserve() method to the raw_ostream..
Feb 19 2021, 1:20 PM · Restricted Project
avl added inline comments to D91693: [Support] Add reserve() method to the raw_ostream..
Feb 19 2021, 7:00 AM · Restricted Project

Feb 15 2021

avl updated the summary of D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..
Feb 15 2021, 4:55 AM · Restricted Project
avl added a comment to D91028: [llvm-objcopy][NFC] replace class Buffer/MemBuffer/FileBuffer with streams..

short summary why that refactoring is useful: It replaces specialized interfaces Buffer/MemBuffer/FileBuffer with more general interface - raw_ostream. It allows easily redefine the type of destination. It also allows to work effectively for implementations which do not pre-allocate destination space.

Feb 15 2021, 4:51 AM · Restricted Project
avl added a comment to D91693: [Support] Add reserve() method to the raw_ostream..

ping.

Feb 15 2021, 4:43 AM · Restricted Project

Feb 8 2021

avl updated the summary of D91693: [Support] Add reserve() method to the raw_ostream..
Feb 8 2021, 9:11 AM · Restricted Project
avl updated the diff for D91693: [Support] Add reserve() method to the raw_ostream..

removed usages of memory mapped file. make reserve() method to
pre-allocate internal buffers only.

Feb 8 2021, 8:30 AM · Restricted Project