Page MenuHomePhabricator

steven_wu (Steven Wu)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 4 2014, 3:46 PM (254 w, 5 d)

Recent Activity

Mon, Sep 16

steven_wu added a comment to D67568: [LTO][Legacy] Add new C inferface to query libcall functions.

I break this into two commits. r372021 and r372022.

Mon, Sep 16, 11:53 AM · Restricted Project
steven_wu committed rGdd63b9f570da: [lld] Update lld driver to use new LTO APIs to handle libcall symbols (authored by steven_wu).
[lld] Update lld driver to use new LTO APIs to handle libcall symbols
Mon, Sep 16, 11:50 AM
steven_wu committed rG34d80461ff77: [LTO][Legacy] Add new C inferface to query libcall functions (authored by steven_wu).
[LTO][Legacy] Add new C inferface to query libcall functions
Mon, Sep 16, 11:50 AM
steven_wu committed rL372022: [lld] Update lld driver to use new LTO APIs to handle libcall symbols.
[lld] Update lld driver to use new LTO APIs to handle libcall symbols
Mon, Sep 16, 11:49 AM
steven_wu committed rL372021: [LTO][Legacy] Add new C inferface to query libcall functions.
[LTO][Legacy] Add new C inferface to query libcall functions
Mon, Sep 16, 11:49 AM
steven_wu closed D67568: [LTO][Legacy] Add new C inferface to query libcall functions.
Mon, Sep 16, 11:49 AM · Restricted Project
steven_wu updated the diff for D67568: [LTO][Legacy] Add new C inferface to query libcall functions.
  • [LTO][Legacy] Add new C inferface to query libcall functions
  • [lld] Update lld to use the new LTO API to add libcall symbols
Mon, Sep 16, 10:09 AM · Restricted Project

Fri, Sep 13

steven_wu added a comment to D67568: [LTO][Legacy] Add new C inferface to query libcall functions.

How many symbols are there today? Do we want this overhead of a function call for each? Could you instead return a count and array pointer (like argc and argv) or have a "foreach" function that takes a block and calls it back for each symbol?

Fri, Sep 13, 3:29 PM · Restricted Project
steven_wu committed rGaa89c5ffc30f: [NFC][libLTO] Rearrange declaration in lto.h (authored by steven_wu).
[NFC][libLTO] Rearrange declaration in lto.h
Fri, Sep 13, 2:22 PM
steven_wu committed rL371900: [NFC][libLTO] Rearrange declaration in lto.h.
[NFC][libLTO] Rearrange declaration in lto.h
Fri, Sep 13, 2:21 PM
steven_wu closed D67565: [NFC][libLTO] Rearrange declaration in lto.h.
Fri, Sep 13, 2:21 PM · Restricted Project
steven_wu added a comment to D67568: [LTO][Legacy] Add new C inferface to query libcall functions.

lto.cpp is not really tested. Maybe we can test this by move this into lib/LTO then integrate the new version into lld?

Fri, Sep 13, 1:05 PM · Restricted Project
steven_wu updated the diff for D67565: [NFC][libLTO] Rearrange declaration in lto.h.
  • [LTO][Legacy] Add new C inferface to query libcall functions
Fri, Sep 13, 12:58 PM · Restricted Project
steven_wu added a comment to D67565: [NFC][libLTO] Rearrange declaration in lto.h.

Sorry, should be clear that this is for doxygen documents. See @defgroup @ingroup from the comments. Those functions where in the Caching APIs group.

I don't see LLVM website is generating documents based on groups but still good to get it correct.

Just want to clean this up because I am planning to add some new APIs.

I get why they don't belong in the caching section, but now they are in the ThinLTO-specific section (LLVMCTLTO). Should they be in the earlier LLVMCLTO section which seems to include more of the generic LTO interfaces?

Fri, Sep 13, 12:53 PM · Restricted Project
steven_wu added a child revision for D67565: [NFC][libLTO] Rearrange declaration in lto.h: D67568: [LTO][Legacy] Add new C inferface to query libcall functions.
Fri, Sep 13, 12:32 PM · Restricted Project
steven_wu added a parent revision for D67568: [LTO][Legacy] Add new C inferface to query libcall functions: D67565: [NFC][libLTO] Rearrange declaration in lto.h.
Fri, Sep 13, 12:32 PM · Restricted Project
steven_wu created D67568: [LTO][Legacy] Add new C inferface to query libcall functions.
Fri, Sep 13, 12:32 PM · Restricted Project
steven_wu added a comment to D67565: [NFC][libLTO] Rearrange declaration in lto.h.

Sorry, should be clear that this is for doxygen documents. See @defgroup @ingroup from the comments. Those functions where in the Caching APIs group.

Fri, Sep 13, 11:24 AM · Restricted Project
steven_wu created D67565: [NFC][libLTO] Rearrange declaration in lto.h.
Fri, Sep 13, 10:40 AM · Restricted Project
steven_wu added a comment to D67559: [Sema] Split of versions of -Wimplicit-{float,int}-conversion for Objective-C BOOL.

The diagnostics message looks good to me.

Fri, Sep 13, 10:35 AM · Restricted Project, Restricted Project

Fri, Sep 6

steven_wu added inline comments to D59709: [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible.
Fri, Sep 6, 4:03 PM · Restricted Project
steven_wu added inline comments to D59709: [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible.
Fri, Sep 6, 1:18 PM · Restricted Project

Thu, Sep 5

steven_wu added inline comments to D59709: [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible.
Thu, Sep 5, 9:54 AM · Restricted Project

Wed, Sep 4

steven_wu added a comment to D59709: [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible.

Hi Teresa, I am seeing some regressions because of this commit. ThinLTO is now producing more weak symbols than before and I am looking for a good fix. See inline comments for details.

Wed, Sep 4, 6:19 PM · Restricted Project
steven_wu committed rL370935: Request commit access for steven_wu.
Request commit access for steven_wu
Wed, Sep 4, 10:33 AM

Tue, Sep 3

steven_wu abandoned D65532: [LTO][Legacy] Update TargetOption after parsing debug options.
Tue, Sep 3, 9:27 AM · Restricted Project

Aug 13 2019

steven_wu added a comment to D66159: [Object] Add tapi files to object.

We can discuss what is a good class name for TapiFile and TapiUniversal. It should be consistent with the other patch as well.

Aug 13 2019, 2:04 PM · Restricted Project
steven_wu accepted D66149: [BinaryFormat] Teach identify_magic about Tapi files..

few small comments. Otherwise, LGTM.

Aug 13 2019, 1:38 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project
steven_wu accepted D66147: [TextAPI] Update reader to be supported by lib/Object.

LGTM

Aug 13 2019, 1:29 PM · Restricted Project
steven_wu committed rG9e51fb6c5762: [AutoUpgrader] Make ArcRuntime Autoupgrader more conservative (authored by steven_wu).
[AutoUpgrader] Make ArcRuntime Autoupgrader more conservative
Aug 13 2019, 10:53 AM
steven_wu committed rL368730: [AutoUpgrader] Make ArcRuntime Autoupgrader more conservative.
[AutoUpgrader] Make ArcRuntime Autoupgrader more conservative
Aug 13 2019, 10:52 AM
steven_wu closed D66153: [AutoUpgrader] Make ArcRuntime Autoupgrader more conservative.
Aug 13 2019, 10:52 AM · Restricted Project
steven_wu created D66153: [AutoUpgrader] Make ArcRuntime Autoupgrader more conservative.
Aug 13 2019, 10:36 AM · Restricted Project

Aug 12 2019

steven_wu accepted D66047: Do not call replaceAllUsesWith to upgrade calls to ARC runtime functions to intrinsic calls.
Aug 12 2019, 12:28 PM · Restricted Project
steven_wu added inline comments to D66047: Do not call replaceAllUsesWith to upgrade calls to ARC runtime functions to intrinsic calls.
Aug 12 2019, 10:32 AM · Restricted Project

Aug 7 2019

steven_wu accepted D65902: [ObjC][ARC] Upgrade calls to ARC runtime functions to intrinsic calls if the bitcode has the arm64 retainAutoreleasedReturnValue marker .

LGTM

Aug 7 2019, 6:31 PM · Restricted Project
steven_wu added a comment to D65902: [ObjC][ARC] Upgrade calls to ARC runtime functions to intrinsic calls if the bitcode has the arm64 retainAutoreleasedReturnValue marker .

From my previous change, we dropped clang.arc.used from the old bitcode. Should we upgrade clang.arc.used instead of dropping them?

Aug 7 2019, 2:27 PM · Restricted Project

Jul 31 2019

steven_wu added a comment to D65532: [LTO][Legacy] Update TargetOption after parsing debug options.

Interesting. I did some digging through bug report as well because I am curious why this is only reported now but didn't find anything.

Jul 31 2019, 3:05 PM · Restricted Project
steven_wu added a comment to D65532: [LTO][Legacy] Update TargetOption after parsing debug options.

Implementation specific to lto.cpp is really hard to write a test. The TargetOptions are cl::opt bring in through "llvm/CodeGen/CommandFlags.inc" so we need a client for libLTO to test this (which we never had). Let me know if you have any suggestions.

Jul 31 2019, 1:46 PM · Restricted Project
steven_wu created D65532: [LTO][Legacy] Update TargetOption after parsing debug options.
Jul 31 2019, 1:06 PM · Restricted Project
steven_wu accepted D65491: [llvm-objdump] Fix jumptable detection when disassembling Mach-O binaries.

LGTM

Jul 31 2019, 8:50 AM · Restricted Project

Jul 30 2019

steven_wu added a comment to D65491: [llvm-objdump] Fix jumptable detection when disassembling Mach-O binaries.

Can you add a test case? You can potentially use llc to generate a .o file from .ll and run disassembler on the object file.

Jul 30 2019, 5:21 PM · Restricted Project

Jul 18 2019

steven_wu committed rGdac7fca530f7: Remove the static initialize introduced in r365099 (authored by steven_wu).
Remove the static initialize introduced in r365099
Jul 18 2019, 2:05 PM
steven_wu committed rL366496: Remove the static initialize introduced in r365099.
Remove the static initialize introduced in r365099
Jul 18 2019, 2:04 PM
steven_wu closed D64873: Remove the static initialize introduced in r365099.
Jul 18 2019, 2:04 PM · Restricted Project
steven_wu added a comment to D64873: Remove the static initialize introduced in r365099.

ping.

Jul 18 2019, 12:24 PM · Restricted Project

Jul 17 2019

steven_wu created D64873: Remove the static initialize introduced in r365099.
Jul 17 2019, 10:45 AM · Restricted Project

Jul 16 2019

steven_wu added a comment to D63735: [MachOObjectFile]Added Valid Architecture Function.

This adds an unnecessary static initializer to the MachOObject.cpp. Can you move the array of validArchs into filescope? You can declare it in getValidArchs() and use getValidArchs() in isValidArchs.

I was hoping that std::array wouldn't necessitate a static initializer, since it's just supposed to be a zero-cost wrapper around a C array.

Jul 16 2019, 11:35 AM · Restricted Project
steven_wu added a comment to D63735: [MachOObjectFile]Added Valid Architecture Function.

This adds an unnecessary static initializer to the MachOObject.cpp. Can you move the array of validArchs into filescope? You can declare it in getValidArchs() and use getValidArchs() in isValidArchs.

Jul 16 2019, 11:17 AM · Restricted Project

Jul 9 2019

steven_wu committed rG65f964c23eb1: Add lit.local.cfg to llvm-objdump tests (authored by steven_wu).
Add lit.local.cfg to llvm-objdump tests
Jul 9 2019, 10:49 AM
steven_wu added a comment to D29044: Add LC_BUILD_VERSION load command.

You need to add a llvm/test/tools/llvm-objdump/lit.local.cfg that contains config.suffixes = ['.yaml'], else the .yaml files added in this change won't be run by lit.

Jul 9 2019, 10:47 AM · Restricted Project
steven_wu committed rL365519: Add lit.local.cfg to llvm-objdump tests.
Add lit.local.cfg to llvm-objdump tests
Jul 9 2019, 10:47 AM
steven_wu added a comment to D64197: [HardwareLoops] NFC - move hardware loop checking code to isHardwareLoopProfitable().

This added an extra dependency from Analysis -> TransformUtils. I don't think this dependency is a good idea, so is adding preheader in analysis pass.

Jul 9 2019, 10:26 AM · Restricted Project

Jun 18 2019

steven_wu accepted D63444: [ThinLTO] Optimize write-only globals out.

LGTM.

Jun 18 2019, 8:30 AM · Restricted Project

Jun 17 2019

steven_wu added a comment to D63444: [ThinLTO] Optimize write-only globals out.

Sounds like an interesting optimization. Is the global storage (from the other module) also eliminated in this case? If so, can you add a testcase for that?

Jun 17 2019, 10:56 AM · Restricted Project

Jun 11 2019

steven_wu accepted D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.

SGTM

Jun 11 2019, 8:23 AM · Restricted Project

Jun 10 2019

steven_wu added a comment to D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.

We should look at either merging the implementations or providing an api function that provides access to the "llvm.linker.options" named metadata via the IRSymtab. It may not be possible to merge the implementations because in COFF and MACHO the representation of dependent libraries is a string of command line options; whereas, the ELF representation is an array of library strings. This is because for COFF and MACHO there is basically only one linker for each file format so the command line format is fixed. For ELF there are a greater variety of linkers, so I just pass the library strings through to the linker, without processing them into command line arguments, and it is deferred to the linker to interpret the library strings.

Jun 10 2019, 4:02 PM · Restricted Project

Jun 7 2019

steven_wu added a comment to D62935: [ThinLTO][LTO][Legacy] Fix dependent libraries support by adding querying of the IRSymtab.

This is ELF specific and miss the initial RFC so there is quite some reading to catch up. Should we merge the MachO implementation together with the ELF one? Once you commit this, you might want to file a bug report on me to catch up on the macho side.

Jun 7 2019, 9:05 AM · Restricted Project

Jun 4 2019

steven_wu accepted D62711: [MACHO] Replaced calls to getStruct with getStructOrErr in functions returning Error or Expected or similar.

LGTM.

Jun 4 2019, 8:15 AM · Restricted Project

May 28 2019

steven_wu updated the diff for D59945: [ObjCMetadata] Add support for reading Objective-C metadata.

Rebase the patch to TOT. Ping again.

May 28 2019, 11:11 AM · Restricted Project

May 14 2019

steven_wu added inline comments to D60162: [ThinLTO] Add module flags for TargetLibraryInfoImpl and use in LTO backends.
May 14 2019, 1:49 PM · Restricted Project, Restricted Project
steven_wu added a comment to D60162: [ThinLTO] Add module flags for TargetLibraryInfoImpl and use in LTO backends.

Thanks for doing this. I think module flag is a good idea. Some comments inline.

May 14 2019, 9:35 AM · Restricted Project, Restricted Project

May 10 2019

steven_wu added a comment to D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone.

Why are you interested in expending this list?

I have a (kernel) that is compiled with -mno-red-zone and -mcmodel=large which I want to compile with -fembed-bitcode for a debugging tool that needs the bitcode.

But I can carry these patches locally for now.

May 10 2019, 8:41 AM · Restricted Project

May 7 2019

steven_wu added a comment to D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone.

Like I said, I am not worried that -mno-red-zone itself changes the ABI. As long as LLVM still respect the attribute the same way, it is fine. I want to consult Tim to make sure we can support re-targeting no red zone from armv7k to arm64_32.

May 7 2019, 11:29 AM · Restricted Project
steven_wu added a comment to D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone.

@steven_wu - yeah, -mred-zone, -mno-red-zone does impact the ABI, at least on x86_64. It changes the way that the arguments are spilled and the stack layout.

May 7 2019, 9:05 AM · Restricted Project
steven_wu added a comment to D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone.

The main concern for adding this blacklist was because of long term maintainability since the option is going to be embedded into bitcode. Looking at this specific option, I have no reason against because it doesn't affect embedded compiler flags.

May 7 2019, 8:54 AM · Restricted Project
steven_wu added a reviewer for D61627: [clang driver] Allow -fembed-bitcode combined with -mno-red-zone: t.p.northover.
May 7 2019, 8:54 AM · Restricted Project

May 2 2019

steven_wu added a comment to D61346: [CMake] Do not use libtool on Apple platforms when building LLVM with (full) LTO..

When you are manually configuring the bootstrap, I still don't think trying to bypass libtool is the correct fix because you still need to specify the correct llvm-ar to use. The default CMAKE_AR inferred by cmake will not work. Maybe it is an option to add the control to force llvm-ar if wished, then you have two options when you manually configuring bootstrap:

May 2 2019, 8:20 AM · Restricted Project

May 1 2019

steven_wu updated the diff for D59945: [ObjCMetadata] Add support for reading Objective-C metadata.

Rebase the patch and did some fixup:

May 1 2019, 9:47 AM · Restricted Project

Apr 30 2019

steven_wu added a comment to D61346: [CMake] Do not use libtool on Apple platforms when building LLVM with (full) LTO..

If you use cmake variable CLANG_ENABLE_BOOTSTRAP, it should take care of DYLD_LIBRARY_PATH so libtool is using the just built libLTO to create static library. The setup of the DYLD_LIBRARY_PATH is just below.

Apr 30 2019, 5:13 PM · Restricted Project
steven_wu added a comment to D61255: [ThinLTO] Make weak data symbols prevailing when they're visible to regular object.

I agree this doesn't look like the correct fix, especially the check !Sym.isExecutable() which doesn't look correct to me

The problem is that linkonce_odr functions and data should be IMO treated differently. The linkonce_odr linkage implies linker leaves only one copy of the symbol in the final image.
However it's not really a problem having multiple internal copies of linkonce_odr function because all copies follow one definition rule. This fact allows ThinLTO to efficiently optimize such function calls.
Situation however is different with linkonce_odr objects, because it's wrong to have multiple copies of linkonce_odr object because reads and writes supposed to access same memory will actually become
inconsistent. However there is still a nuance: if object is a compile time constant there can't be any write access to it, so we can safely internalize it.

Apr 30 2019, 1:36 PM · Restricted Project
steven_wu added a comment to D61255: [ThinLTO] Make weak data symbols prevailing when they're visible to regular object.

I don't see this happening in legacy thinLTO code generator but I need to do more digging to see what is the difference. For legacy API, the static variable is not internalized or turned into available_externally.

Apr 30 2019, 11:22 AM · Restricted Project

Apr 29 2019

steven_wu committed rG6c9f6fd11b65: [ThinLTO] Adding architecture name into saved object filename (authored by steven_wu).
[ThinLTO] Adding architecture name into saved object filename
Apr 29 2019, 2:39 PM
steven_wu committed rL359508: [ThinLTO] Adding architecture name into saved object filename.
[ThinLTO] Adding architecture name into saved object filename
Apr 29 2019, 2:38 PM
steven_wu closed D60924: [ThinLTO] Adding architecture name into saved object filename.
Apr 29 2019, 2:38 PM · Restricted Project
steven_wu added a comment to D60924: [ThinLTO] Adding architecture name into saved object filename.

ping

Apr 29 2019, 10:57 AM · Restricted Project

Apr 19 2019

steven_wu updated the diff for D60924: [ThinLTO] Adding architecture name into saved object filename.

Add tests for the change. There is acutally an easy to test with llvm-lto

Apr 19 2019, 7:12 PM · Restricted Project
steven_wu added a comment to D60924: [ThinLTO] Adding architecture name into saved object filename.

Is there a good way to test this?

Not currently in LLVM. It might be possible to add a test in clang repo which requires DARWIN and ld64.

Maybe we can split out the function to generate the filename, and add a unit test for that?

Apr 19 2019, 3:17 PM · Restricted Project
steven_wu added a comment to D60924: [ThinLTO] Adding architecture name into saved object filename.

Is there a good way to test this?

Apr 19 2019, 2:55 PM · Restricted Project
steven_wu created D60924: [ThinLTO] Adding architecture name into saved object filename.
Apr 19 2019, 2:31 PM · Restricted Project

Apr 17 2019

steven_wu added a comment to D60516: [LTO] Add plumbing to save stats during LTO on Darwin..

forgot to save the inline comments.

Apr 17 2019, 10:51 AM · Restricted Project, Restricted Project
steven_wu accepted D60516: [LTO] Add plumbing to save stats during LTO on Darwin..

LGTM with one additional small comments

Apr 17 2019, 10:51 AM · Restricted Project, Restricted Project
steven_wu committed rG05a358cdcd55: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols (authored by steven_wu).
[ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols
Apr 17 2019, 10:39 AM
steven_wu committed rL358601: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.
[ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols
Apr 17 2019, 10:39 AM
steven_wu closed D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.
Apr 17 2019, 10:39 AM · Restricted Project
steven_wu added a comment to D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

Thanks Teresa and Ben for the feedback! I am landing this change.

Apr 17 2019, 10:34 AM · Restricted Project

Apr 12 2019

steven_wu added a comment to D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

Sorry for the delay in replying. I was trying to understand if the upgrade path was important. Comments inline:

Hi Steven,

I missed that this work was being done - sorry.

Currently the legacy api does not require the IRSymtab to be written to the bitcode files so there is potentially a performance degradation due to this approach and the generated bitcode files will be larger, did you measure that?

The legacy API is not writing out IRSymtab but build that in memory during code generation. The only requirement change is that now data layout is required for thin LTO .

My understanding is that the on disk bitcode contains a binary representation of the IRSymtab and this is read into memory when loading the file (which is why the upgrade path is more expensive than the no-upgrade path). I am saying that currently the legacy api does not require the IRSymtab to be written to disk. Writing it may cost more time and make the input files bigger.

Apr 12 2019, 2:38 PM · Restricted Project

Apr 10 2019

steven_wu added a comment to D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

Hi Steven,

I missed that this work was being done - sorry.

Currently the legacy api does not require the IRSymtab to be written to the bitcode files so there is potentially a performance degradation due to this approach and the generated bitcode files will be larger, did you measure that?

Apr 10 2019, 8:59 AM · Restricted Project

Apr 8 2019

steven_wu updated the diff for D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

Add one file that was missing from previous patch

Apr 8 2019, 2:42 PM · Restricted Project
steven_wu added a comment to D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

What part of the patch caused the need to change the internalize action to do promote+internalize in one go?

Apr 8 2019, 2:11 PM · Restricted Project
steven_wu added a reviewer for D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols: dexonsmith.
Apr 8 2019, 1:48 PM · Restricted Project
steven_wu created D60421: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.
Apr 8 2019, 1:46 PM · Restricted Project
steven_wu added a comment to D60226: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

I reverted this because the old thinLTO test cases need to be updated to have data layout as a requirement to use IRSymtab. I will start a separate review to address all those issues.

Apr 8 2019, 1:18 PM · Restricted Project
steven_wu added a comment to rL357931: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

I reverted this because the old thinLTO test cases need to be updated to have data layout as a requirement to use IRSymtab. I will start a separate review to address all those issues.

Apr 8 2019, 1:18 PM
steven_wu committed rGf41e70d6eb90: Revert [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols (authored by steven_wu).
Revert [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols
Apr 8 2019, 11:53 AM
steven_wu committed rL357932: Revert [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.
Revert [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols
Apr 8 2019, 11:53 AM
steven_wu committed rG8b70a5c11e08: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols (authored by steven_wu).
[ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols
Apr 8 2019, 11:23 AM
steven_wu committed rL357931: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.
[ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols
Apr 8 2019, 11:22 AM
steven_wu closed D60226: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.
Apr 8 2019, 11:22 AM · Restricted Project
steven_wu updated the diff for D60226: [ThinLTO] Fix ThinLTOCodegenerator to export llvm.used symbols.

Review feedback.

Apr 8 2019, 9:30 AM · Restricted Project