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 (228 w, 4 d)

Recent Activity

Yesterday

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

Thanks for explanation. Then the current approach in this patch LGTM. Thanks!

Fri, Mar 22, 3:55 PM · Restricted Project
steven_wu added a comment to D59709: [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible.

I am not quite sure what is the semantics for ELF linker. When thinLTO picks the linkonce_odr version and promote it to weak, it is not changing the visibility. It is a later linker optimization that auto hide the linkonce_odr symbol, correct?

It is in fact ThinLTO that is changing the visibility (D43130). See the change I made to FunctionImport.cpp.

Interesting, I made that change! But I somehow remembered I got pushed back because of ELF semantics and end up implementing that in ld64 instead. Let me dig up some context and get back to you.

Are you thinking of https://reviews.llvm.org/D43361?

Fri, Mar 22, 2:56 PM · Restricted Project
steven_wu added a comment to D59709: [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible.

I am not quite sure what is the semantics for ELF linker. When thinLTO picks the linkonce_odr version and promote it to weak, it is not changing the visibility. It is a later linker optimization that auto hide the linkonce_odr symbol, correct?

It is in fact ThinLTO that is changing the visibility (D43130). See the change I made to FunctionImport.cpp.

Fri, Mar 22, 2:04 PM · Restricted Project
steven_wu added a comment to D59709: [ThinLTO] Auto-hide prevailing linkonce_odr only when all copies eligible.

I am not quite sure what is the semantics for ELF linker. When thinLTO picks the linkonce_odr version and promote it to weak, it is not changing the visibility. It is a later linker optimization that auto hide the linkonce_odr symbol, correct?

Fri, Mar 22, 1:29 PM · Restricted Project

Thu, Mar 21

steven_wu committed rG5a593547602b: [Object] Fix reading objects created with -fembed-bitcode-marker (authored by steven_wu).
[Object] Fix reading objects created with -fembed-bitcode-marker
Thu, Mar 21, 2:02 PM
steven_wu committed rL356718: [Object] Fix reading objects created with -fembed-bitcode-marker.
[Object] Fix reading objects created with -fembed-bitcode-marker
Thu, Mar 21, 2:00 PM
steven_wu closed D44373: Fix reading objects created with -fembed-bitcode-marker..
Thu, Mar 21, 2:00 PM · Restricted Project
steven_wu added a comment to D44373: Fix reading objects created with -fembed-bitcode-marker..

Thanks for fixing this. LGTM.

Looks like this never actually got committed?

Thu, Mar 21, 1:50 PM · Restricted Project

Thu, Mar 7

steven_wu committed rGed9822928626: [Bitcode] Fix bitcode compatibility issue with clang.arc.use intrinsic (authored by steven_wu).
[Bitcode] Fix bitcode compatibility issue with clang.arc.use intrinsic
Thu, Mar 7, 9:28 PM
steven_wu committed rL355663: [Bitcode] Fix bitcode compatibility issue with clang.arc.use intrinsic.
[Bitcode] Fix bitcode compatibility issue with clang.arc.use intrinsic
Thu, Mar 7, 9:27 PM
steven_wu closed D59112: [Bitcode] Fix bitcode compatibility issue with clang.arc.use intrinsic.
Thu, Mar 7, 9:27 PM · Restricted Project
steven_wu created D59112: [Bitcode] Fix bitcode compatibility issue with clang.arc.use intrinsic.
Thu, Mar 7, 2:50 PM · Restricted Project

Feb 13 2019

steven_wu accepted D58122: Restore Check for Unreachable Exit Block in -Winfinite-recursion.

LGTM

Feb 13 2019, 9:18 AM · Restricted Project, Restricted Project

Feb 12 2019

steven_wu accepted D58071: Fix auto-upgrade for the new parameter to llvm.objectsize.

LGTM.

Feb 12 2019, 1:38 PM · Restricted Project

Feb 11 2019

steven_wu added a comment to D58071: Fix auto-upgrade for the new parameter to llvm.objectsize.

I talked to Erik offline. I think the upgrade tests should run on .bc file rather than text format.

Feb 11 2019, 3:38 PM · Restricted Project
steven_wu accepted D57991: [Driver][Darwin] Emit an error when using -pg on OS without support for it..

LGTM with a suggestion to make code cleaner.

Feb 11 2019, 11:02 AM · Restricted Project

Feb 7 2019

Herald added a project to D43737: Improve -Winfinite-recursion: Restricted Project.

Sorry for following up late on the patch. Removing the reachability testing for the exit block causes false positive for infinite loop cases like this:

Feb 7 2019, 11:34 AM · Restricted Project

Jan 29 2019

steven_wu committed rC352537: Fix the tests from r350970.
Fix the tests from r350970
Jan 29 2019, 12:13 PM
steven_wu committed rL352537: Fix the tests from r350970.
Fix the tests from r350970
Jan 29 2019, 12:13 PM

Jan 17 2019

steven_wu accepted D56805: mac: Correctly disable tools/lto tests when building with LLVM_ENABLE_PIC=OFF.

Not sure about gn part and if that has any impact. Otherwise, LGTM.

Jan 17 2019, 3:45 PM

Jan 11 2019

steven_wu committed rL350970: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO.
[Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO
Jan 11 2019, 1:20 PM
steven_wu committed rC350970: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO.
[Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO
Jan 11 2019, 1:20 PM
steven_wu closed D56608: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO.
Jan 11 2019, 1:20 PM
steven_wu updated the diff for D56608: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO.

Fix the comment

Jan 11 2019, 11:09 AM
steven_wu updated the diff for D56608: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO.

I was planning to add a test but I am not sure how to check the file type of temporary files.

Jan 11 2019, 10:55 AM
steven_wu created D56608: [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO.
Jan 11 2019, 9:33 AM

Jan 7 2019

steven_wu added a comment to D53945: [TextAPI] TBD Reader/Writer.

Out of interest, why aren't most of the tests for this lit tests? The usual llvm way of testing stuff is to write a small llvm tool using your library (which will be useful outside of a testing context too) and then use that to write lit tests.

Looks like this is now happening (rL350341). Are most of the unit tests going to move to lit tests now?

Jan 7 2019, 10:05 AM · Restricted Project

Dec 17 2018

steven_wu added a comment to D55080: [ThinLTO] Out-of-process CodeGenerator for legacy C API.

Thanks for the clarifications. Would it be possible to utilize ThinBackendProc for this instead of a new CodeGenManager class? I.e. make a new derived version that does the index file write and spawns the local processes? The advantage is that it would start converging the implementations. And I think this could aid in refactoring suggested below to avoid duplication. Another advantage is that both LTO API's would have access to all backend implementations (in process, write indexes and exit, write indexes and use local processes, etc).

Dec 17 2018, 11:03 AM
steven_wu added inline comments to D55673: [darwin] parse the SDK settings from SDKSettings.json if it exists and pass in the -target-sdk-version to the compiler and backend.
Dec 17 2018, 10:38 AM
steven_wu accepted D55673: [darwin] parse the SDK settings from SDKSettings.json if it exists and pass in the -target-sdk-version to the compiler and backend.

Other than a small design choice commented inline, LGTM.

Dec 17 2018, 10:18 AM

Dec 13 2018

steven_wu added a comment to D55673: [darwin] parse the SDK settings from SDKSettings.json if it exists and pass in the -target-sdk-version to the compiler and backend.

See comments inline.

Dec 13 2018, 2:35 PM

Dec 12 2018

steven_wu accepted D55612: [macho] save the SDK version stored in module metadata into the version min and build version load commands in the object file.

I think I missed something before. LGTM now!

Dec 12 2018, 3:58 PM
steven_wu added a comment to D55612: [macho] save the SDK version stored in module metadata into the version min and build version load commands in the object file.

Don't we need IR support for this as well? sdk version is not in the triple so it is going to get lost when building from IR. Maybe use a metadata node?

I provide a way to set and retrieve the SDK version from the IR using the "SDK Version" metadata. Do I need something more than that? Clang can set it and we are already getting it in this patch.

Dec 12 2018, 3:30 PM
steven_wu added a comment to D55612: [macho] save the SDK version stored in module metadata into the version min and build version load commands in the object file.

Don't we need IR support for this as well? sdk version is not in the triple so it is going to get lost when building from IR. Maybe use a metadata node?

Dec 12 2018, 2:00 PM
steven_wu added a comment to D55080: [ThinLTO] Out-of-process CodeGenerator for legacy C API.

Thanks for taking a look. This patch is adding the customization points for thinLTO legacy API, which the code generator constructs clang invocations to do code generation. There is no dependency on any build system here and it only has a prove of concept codegen manager which invokes clang directly and collect the result back. You can replace this codegen manager with any protocol that is needed to talk to build system to run clang codegen.
XPC is the way to send information between process on Darwin, which is probably what we are going to use to talk to build system. If interested, I can post a patch which have example how to construct XPC communications, but there isn’t a build system you can use to listen on the other side to run the job yet.
When I say there are no code change for linker, I really mean there is no need to change a single line of code (maybe we need to add an API to select codegen manager in the future). ld64 really has a different approach using C API, which it tries to map the object file output back to the bitcode it gets as input. Terminating and relaunching the linker might has unexpected semantic changes for LTO. In the long run, maybe ld64 needs to design a new set of APIs to use the new C++ APIs but this is out of scope of this patch.

Dec 12 2018, 11:57 AM
steven_wu added a comment to D55080: [ThinLTO] Out-of-process CodeGenerator for legacy C API.

Ping. Is there any comments of implementing C API in this approach?

Dec 12 2018, 11:16 AM
steven_wu committed rL348943: [Driver] Add support for -fembed-bitcode for assembly file.
[Driver] Add support for -fembed-bitcode for assembly file
Dec 12 2018, 9:33 AM
steven_wu committed rC348943: [Driver] Add support for -fembed-bitcode for assembly file.
[Driver] Add support for -fembed-bitcode for assembly file
Dec 12 2018, 9:33 AM
steven_wu closed D55525: [Driver] Add support for -fembed-bitcode for assembly file.
Dec 12 2018, 9:33 AM

Dec 11 2018

steven_wu added a comment to D55525: [Driver] Add support for -fembed-bitcode for assembly file.

This really feels odd. Why not expect that the developer will add the content themselves? I'm not sure I understand the motivation for this change.

Dec 11 2018, 4:37 PM

Dec 10 2018

steven_wu created D55525: [Driver] Add support for -fembed-bitcode for assembly file.
Dec 10 2018, 11:04 AM
steven_wu abandoned D21230: Do not embed all the cc1 options in bitcode commandline.

This is upstreamed by Saleem already

Dec 10 2018, 11:04 AM

Nov 29 2018

steven_wu created D55080: [ThinLTO] Out-of-process CodeGenerator for legacy C API.
Nov 29 2018, 2:56 PM

Nov 26 2018

steven_wu accepted D54635: [ThinLTO] Consolidate cache key computation between new/old LTO APIs.

I did some experiment and put some more thought into this patch. Not hashing PreservedSymbol passed to the C API is fine because the reason you mentioned but freestanding/no-builtin bits stills need to be handled separately in current status. That should be a different discussion so this patch is LGTM.

Nov 26 2018, 10:06 AM

Nov 16 2018

steven_wu added a comment to D54635: [ThinLTO] Consolidate cache key computation between new/old LTO APIs.

I wonder freestanding is still an issue after r316819. There is a function attribute for that now so it should be respected if the module is built with -ffreestanding and it should create different hash. I will do some digging to see if I can find the original report and how they setup the build. @mehdi_amini, do you remember the original problem?

Nov 16 2018, 11:03 AM

Nov 14 2018

steven_wu accepted D54542: Remove unused getMDNodeFwdRefOrNull interfaces (NFC).

Thanks!

Nov 14 2018, 1:54 PM
steven_wu added a comment to D53596: [ThinLTO] Fix a crash in lazy loading of Metadata.

Steven - you had a suggestion around callers to getMDNodeFwdRefOrNull, but after this change there will be no more callers to that. So should I go ahead and submit this one, then remove that interface completely in a follow up? Or do it in this patch?

Nov 14 2018, 12:11 PM
steven_wu added a comment to D53596: [ThinLTO] Fix a crash in lazy loading of Metadata.

My thought is that this patch should make bitcode reader more robust when lazy loading, which is always a good thing. If this is a performance regression, the regression is coming from how debug information is generated. If there are no such forward-ref in the metadata, there is no slowdown with this patch. We can investigate performance regression post commit if needed.

Nov 14 2018, 11:17 AM

Nov 13 2018

steven_wu added a comment to D49362: [ThinLTO] Internalize read only globals.

I reverted this in r346768.

Nov 13 2018, 9:53 AM
steven_wu committed rL346768: Revert "[ThinLTO] Internalize readonly globals".
Revert "[ThinLTO] Internalize readonly globals"
Nov 13 2018, 9:38 AM

Nov 12 2018

steven_wu added a comment to D49362: [ThinLTO] Internalize read only globals.

This commit causes our internal bots failed to bootstrap clang. The error we are getting is:

"gCrashRecoveryEnabled (.llvm.1401930837577591816)", referenced from:
    clang::ParseAST(clang::Sema&, bool, bool) in 286.thinlto.o

I have a bit trouble to reproduce the problem but it is 100% reproducible on our bots. I suspect the issue is ThinLTO cache reuse because if I clear the cache then the link will succeed. I will update if I can reproduce and pinpoint the issue.

Nov 12 2018, 6:07 PM

Nov 5 2018

steven_wu accepted D53596: [ThinLTO] Fix a crash in lazy loading of Metadata.

Oh, I see. This is not really related to the debug information quality. It is a pure metadata lazy loading problem. LGTM.

Nov 5 2018, 11:02 AM

Oct 25 2018

steven_wu added a comment to D53596: [ThinLTO] Fix a crash in lazy loading of Metadata.
In D53596#1272986, @vsk wrote:

Thanks for the patch! Your explanation makes sense to me, but I'm not familiar enough with this code to give a +1. @steven_wu, any thoughts on this?

Oct 25 2018, 9:00 AM

Oct 11 2018

steven_wu added a comment to D52836: [LTO] Account for overriding lib calls via the alias attribute.

You need to do a release build without assertion. Local names like parameters are dropped from IR to save space/memory.
I think you just need to check the parameter name or the implementation in your test case.

Oct 11 2018, 12:57 PM

Oct 9 2018

steven_wu added a comment to D53051: [llvm-tapi] initial commit, supports ELF text stubs.

Thanks for posting this. I will start with some high level comments.

Oct 9 2018, 5:27 PM

Sep 26 2018

steven_wu committed rL343124: [libLTO] Expose LLVMCreateDisasmCPUFeatures from libLTO.
[libLTO] Expose LLVMCreateDisasmCPUFeatures from libLTO
Sep 26 2018, 9:51 AM

Sep 24 2018

steven_wu added a comment to D52252: Driver: render arguments for the embedded bitcode correctly.

Thanks for doing this!

Sep 24 2018, 10:03 AM

Sep 14 2018

steven_wu committed rL342263: [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool.
[ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool
Sep 14 2018, 12:39 PM
steven_wu closed D52049: [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool.
Sep 14 2018, 12:39 PM
steven_wu updated the diff for D52049: [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool.

Update comments

Sep 14 2018, 12:38 PM

Sep 13 2018

steven_wu updated the diff for D52049: [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool.

Update patch

Sep 13 2018, 4:23 PM
steven_wu added a comment to D52049: [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool.

Also a bit clarification why ModuleToDefinedGVSummaries can have missing entries, because there can be an empty module, or a module has no GV in it. And this happens during thinLTO WebKit.
For example, in WebCore MacOS build, UnifiedSource26-mm.o has empty text and data section. Its object file only has debug info.

Sep 13 2018, 4:01 PM
steven_wu updated the diff for D52049: [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool.

Fix up my previous patch.

Sep 13 2018, 12:05 PM
steven_wu added a comment to D52049: [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool.

I can't find a super clean solution for this. Here is one possible solution, which is to iterate and insert the entry before entering thread pool

Sep 13 2018, 11:10 AM
steven_wu created D52049: [ThinLTOCodeGenerator] Avoid Rehash StringMap in ThreadPool.
Sep 13 2018, 11:08 AM
steven_wu accepted D52023: [ThinLTO]Allow setting of maximum cache size with 64-bit number, and provide C-interface function for large values.

LGTM

Sep 13 2018, 10:02 AM

Sep 7 2018

steven_wu accepted D51693: ADT: add <bit> header, implement C++20 bit_cast, use.

LGTM!

Sep 7 2018, 11:14 AM

Sep 5 2018

steven_wu added a comment to D51440: [ToolChains] Link to compiler-rt with -L + -l when possible.

I do prefer the current approach especially on Darwin. Some concerns of switching to use "-L + -l" are:

  1. clang and compiler-rt are rev-locked. Inferring the compiler-rt from resource-dir and passing to linker with the full path can prevent mistakes of mixing them up.
  2. This change does change linker semantics on Darwin. ld64 treats the inputs from command line with highest priority. Currently ld64 will use compiler-rt symbols before any other libraries passed in with -l flag. If clang decide to pass compiler-rt with -l flag, any other libraries (static or dynamic) that passed with -l flag will takes the priority over compiler-rt. This can lead to unexpected behavior.
Sep 5 2018, 3:47 PM

Sep 4 2018

steven_wu committed rL341422: [ThinLTO] Fix memory corruption in ThinLTOCodeGenerator when CodeGenOnly was….
[ThinLTO] Fix memory corruption in ThinLTOCodeGenerator when CodeGenOnly was…
Sep 4 2018, 3:55 PM
steven_wu closed D51651: [ThinLTO] Fix memory corruption in ThinLTOCodeGenerator when CodeGenOnly was specified.
Sep 4 2018, 3:55 PM
steven_wu accepted D51651: [ThinLTO] Fix memory corruption in ThinLTOCodeGenerator when CodeGenOnly was specified.

LGTM. Thanks!

Sep 4 2018, 3:29 PM
steven_wu requested changes to D51651: [ThinLTO] Fix memory corruption in ThinLTOCodeGenerator when CodeGenOnly was specified.

Remove the declaration in ThinLTOCodeGenerator.h?

Sep 4 2018, 3:18 PM
steven_wu added a comment to D51651: [ThinLTO] Fix memory corruption in ThinLTOCodeGenerator when CodeGenOnly was specified.

I dont mind removing codege(). This interface exists since the first prototype and no longer exposed through C API. It seems to have the same model of optimize(), which is also not thread safe. optimize() is still used by llvm-lto but not in thread context.

Sep 4 2018, 1:56 PM
steven_wu added a comment to D51651: [ThinLTO] Fix memory corruption in ThinLTOCodeGenerator when CodeGenOnly was specified.

I don't think we need another instance of TMBuilder. Can we just call codegenModule directly from run()? TMBuilder should be initialized already from addModule.

Sep 4 2018, 1:07 PM

Aug 23 2018

steven_wu added a comment to D51189: [Sema][ObjC] Infer availability of +new from availability of -init.

I feel like this is a much tricky situation than just new and init. Following example is the same situation.

__attribute__((objc_root_class))
@interface NSObject
- (void) foo;
- (void) bar;
@end
Aug 23 2018, 7:02 PM

Jul 31 2018

steven_wu added inline comments to D50066: [IRMover] Don't materialise values from different source module.
Jul 31 2018, 11:48 AM
steven_wu added a comment to D50066: [IRMover] Don't materialise values from different source module.

Can you add a bit more explanation other than just saying fixing PR38372?

Jul 31 2018, 9:14 AM

Jul 20 2018

steven_wu added a comment to D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).
In D49434#1170267, @pcc wrote:

I would imagine that folks who care about code size would be linking with --gc-sections (or -dead_strip in ld64) so the library functions would end up being dropped if they aren't actually needed.

Jul 20 2018, 1:46 PM
steven_wu added a comment to D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).

For the old API, I don't think it is reasonable to expect user or linker to pass in the correct preserve list. There is likely no knowledge outside the LTO modules that these lib funcs are needed.

Jul 20 2018, 11:34 AM

Jul 18 2018

steven_wu added a comment to D49434: Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169).
In D49434#1165612, @pcc wrote:

You wouldn't be making changes to the IR, only the summary. I was thinking that you might add code to http://llvm-cs.pcc.me.uk/lib/Analysis/ModuleSummaryAnalysis.cpp#534 that would effectively do:

if (ValueInfo VI = Index.getValueInfo(GlobalValue::getGUID("memcpy")))
    for (auto &Summary : VI.getSummaryList())
      Summary->setLive(true);
if (ValueInfo VI = Index.getValueInfo(GlobalValue::getGUID("memmove")))
    for (auto &Summary : VI.getSummaryList())
      Summary->setLive(true);
// etc.

If I recall correctly it wasn't the LTO dead code elimination that was removing them. Caroline, I forget what was happening in the original case - were they being internalized by LTO and then eliminated by GlobalDCE? If so, then Peter's approach should fix the issue by preventing them from being internalized (at least by ThinLTO, not sure about regular LTO).

Jul 18 2018, 10:15 AM

Jul 16 2018

steven_wu added a comment to D49362: [ThinLTO] Internalize read only globals.

When importing a variable definition when the ref has this bit set, it can be imported as a local copy, without promoting the name/linkage type. That will avoid the need to do any modification to the optimization passes. On the exporting side, we could do prevent the promotion if we knew that all modules importing a reference also imported the referenced variable definition. It does however look like we should be importing all non-interposable linkage constant variables that are referenced, which should be all we care about for this anyway.

What if the constant is really big? Looks like the importing decision has to be made by the thin linker directly. You can not import the "constant" global as something like "available_externally constant" because the original copy might not be visible from the original module (just like the example), unless you want to modify the original copy to be "external hidden".

Not sure I understand your question, can you clarify the concern? Right now, computeImportForReferencedGlobals during the thin link we import any referenced variable, unless it has interposable linkage or references other summaries (in which case it is not a constant). The imported variables are imported as available externally definitions. The original definition is currently promoted to external hidden.

Jul 16 2018, 10:09 AM
steven_wu added a comment to D49362: [ThinLTO] Internalize read only globals.

When importing a variable definition when the ref has this bit set, it can be imported as a local copy, without promoting the name/linkage type. That will avoid the need to do any modification to the optimization passes. On the exporting side, we could do prevent the promotion if we knew that all modules importing a reference also imported the referenced variable definition. It does however look like we should be importing all non-interposable linkage constant variables that are referenced, which should be all we care about for this anyway.

Jul 16 2018, 10:00 AM

Jul 10 2018

steven_wu accepted D48783: [ThinLTO] Use std::map to get determistic imports files.

LGTM. Thanks!

Jul 10 2018, 9:25 AM

Jul 9 2018

steven_wu committed rL336574: Add bitcode compatibility test for 6.0.
Add bitcode compatibility test for 6.0
Jul 9 2018, 11:02 AM
steven_wu closed D49086: Add bitcode compatibility test for 6.0.
Jul 9 2018, 11:02 AM
steven_wu created D49086: Add bitcode compatibility test for 6.0.
Jul 9 2018, 9:58 AM
steven_wu committed rL336560: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.
[BitcodeReader] Infer the correct runtime preemption for GlobalValue
Jul 9 2018, 9:57 AM
steven_wu closed D49039: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.
Jul 9 2018, 9:57 AM

Jul 6 2018

steven_wu updated the diff for D49039: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.

Add testcase using 6.0 bitcode.

Jul 6 2018, 7:20 PM
steven_wu updated the diff for D49039: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.

Address review feedback

Jul 6 2018, 4:06 PM
steven_wu abandoned D49048: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.

oops, accidentally opened a new review. closing.

Jul 6 2018, 4:03 PM
steven_wu created D49048: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.
Jul 6 2018, 4:02 PM
steven_wu added a comment to D49039: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.

In that case, we can enable verification on checked-in bitcode files as a follow-up. How about testing this by round-tripping textual IR through llvm-as and llvm-dis? You just need a function, alias, and global var with local linkage and without dso_local set, right?

Jul 6 2018, 4:01 PM
steven_wu added a comment to D49039: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.
In D49039#1154801, @vsk wrote:

Thanks for doing this!

Could you add a test? Adding "opt -verify <old-bitcode-file>" run lines to the compatibility tests would be fine.

Jul 6 2018, 3:18 PM
steven_wu created D49039: [BitcodeReader] Infer the correct runtime preemption for GlobalValue.
Jul 6 2018, 1:36 PM

Jul 2 2018

steven_wu committed rC336168: [Driver][Darwin] Use Host Triple to infer target os version.
[Driver][Darwin] Use Host Triple to infer target os version
Jul 2 2018, 9:20 PM
steven_wu committed rL336168: [Driver][Darwin] Use Host Triple to infer target os version.
[Driver][Darwin] Use Host Triple to infer target os version
Jul 2 2018, 9:20 PM
steven_wu closed D48849: [Driver][Darwin] Use Host Triple to infer target os version.
Jul 2 2018, 9:20 PM
steven_wu updated the diff for D48849: [Driver][Darwin] Use Host Triple to infer target os version.

It is easier and cleaner if I just fold everything into getOSVersion.

Jul 2 2018, 6:01 PM
steven_wu updated the diff for D48849: [Driver][Darwin] Use Host Triple to infer target os version.

handle *-apple-macosx target option

Jul 2 2018, 4:18 PM