Page MenuHomePhabricator
Feed Advanced Search

Today

fhahn added inline comments to D94630: [LTO] Add support for existing Config::Freestanding option..
Thu, Jan 21, 1:26 PM · Restricted Project
fhahn updated the diff for D94630: [LTO] Add support for existing Config::Freestanding option..

handle freestanding also for runNewPMPasses, add test for runNewPMCustomPasses.

Thu, Jan 21, 1:25 PM · Restricted Project
fhahn updated subscribers of D94630: [LTO] Add support for existing Config::Freestanding option..

LGTM. Did you figure out the answer of your inline comment?

Thu, Jan 21, 9:38 AM · Restricted Project
fhahn added inline comments to D94869: [LV] Fix crash when computing max VF too early.
Thu, Jan 21, 9:15 AM · Restricted Project
fhahn added inline comments to D92282: [VPlan] Handle scalarized values in VPTransformState..
Thu, Jan 21, 8:51 AM · Restricted Project
fhahn updated the diff for D92282: [VPlan] Handle scalarized values in VPTransformState..

Remove unnecessary variable

Thu, Jan 21, 8:51 AM · Restricted Project
fhahn updated the diff for D92282: [VPlan] Handle scalarized values in VPTransformState..

Address Gil's comments, thanks!

Thu, Jan 21, 8:48 AM · Restricted Project
fhahn added a comment to D94883: [CodeGen][SelectionDAG]Add new intrinsic experimental.vector.reverse.

Mirroring my comments for D94708: if the intrinsics needs to support fixed vectors, it would be good to have some tests for platforms other than AArch64 and also support in GlobalISel, which is the default on AArch64 with -O0 IIRC (or do the transform to shuffles as an IR transform).

Thu, Jan 21, 8:40 AM · Restricted Project
fhahn added a comment to D94708: [IR] Introduce llvm.experimental.vector.splice intrinsic.

Are there plans to use this for fixed vectors as well? If not, can this be restricted to scalable vectors only? It seems like for fixed vectors, preferring the shufflevector versions would be beneficial, to avoid having to update all transforms lookin at shuffles.

Otherwise, this should probably have some tests for platforms other than AArch64 and also support in GlobalISel, which is the default on AArch64 with -O0 IIRC (or do the transform to shuffles as an IR transform).

The named shufflevector intrinsics accept both fixed and scalable vectors but for fixed they map to existing shufflevector.

Thu, Jan 21, 8:38 AM · Restricted Project
fhahn added inline comments to D93476: [LV][ARM] Inloop reduction cost modelling.
Thu, Jan 21, 7:06 AM · Restricted Project
fhahn added inline comments to D93476: [LV][ARM] Inloop reduction cost modelling.
Thu, Jan 21, 7:05 AM · Restricted Project
fhahn added inline comments to D94996: [GVN] do not repeat PRE on failure to split critical edge.
Thu, Jan 21, 2:35 AM · Restricted Project
fhahn committed rGbee486851c1a: [LoopUnswitch] Implement first version of partial unswitching. (authored by fhahn).
[LoopUnswitch] Implement first version of partial unswitching.
Thu, Jan 21, 1:47 AM
fhahn closed D93764: [LoopUnswitch] Implement first version of partial unswitching..
Thu, Jan 21, 1:47 AM · Restricted Project
fhahn planned changes to D94597: [X86] Lower calls with rv_marker attribute..

After checking with @ahatanak, we need a slightly different approach on X86 compared to ARM64. I'll update the patch shortly.

Thu, Jan 21, 1:28 AM · Restricted Project

Yesterday

fhahn accepted D94447: [PredicateInfo] Generalize processing of conditions.

LGTM, thanks

Wed, Jan 20, 10:45 AM · Restricted Project
fhahn added inline comments to D94378: [LoopDeletion] Handle inner loops w/untaken backedges.
Wed, Jan 20, 10:42 AM · Restricted Project
fhahn added a comment to D94378: [LoopDeletion] Handle inner loops w/untaken backedges.

Here's the compile-time numbers for the patch: http://llvm-compile-time-tracker.com/compare.php?from=e377c8eeb4aa2eb239a651f1fe12c27fc77deda3&to=8a40070dec65fe8b716cbfbf134f405fc3d26f8a&stat=instructions

Wed, Jan 20, 10:38 AM · Restricted Project
fhahn added a comment to D93764: [LoopUnswitch] Implement first version of partial unswitching..

Thanks everyone for the feedback. I am planning on landing the change tomorrow.

Wed, Jan 20, 10:20 AM · Restricted Project
fhahn added a comment to D94630: [LTO] Add support for existing Config::Freestanding option..

ping

Wed, Jan 20, 9:00 AM · Restricted Project
fhahn accepted D94712: Do not traverse ConstantData use-list in LoopInterchange.

Do not traverse ConstantData use-list in LookInterchange

There's a typo in the title: LookInterchange -> LoopInterchange. Please adjust before committing.

Wed, Jan 20, 7:51 AM · Restricted Project
fhahn added a comment to D93789: Add accessors for MCSubtargetInfo CPU and Feature tables.

I’m not against this, but do want to mention the help text is incorrect for x86-64. It lists CPUs that don’t support 64-bit. Using one of those CPUs will trigger a fatal error. A better list is fillValidCPUList from X86TargetParser.cpp in lib/Support. It takes a mode argument. That’s the interface clang uses.

The fillValidCPUArchList() interface looks pretty annoying in that it's non-virtual. One needs to call different helper functions for each target.

Wed, Jan 20, 7:48 AM · Restricted Project
fhahn requested changes to D84450: Testcase for "More conservatively report status from LoopIdiomRecognize".

Thanks for sharing, but I don;t think this is needed any longer.

Wed, Jan 20, 7:41 AM · Restricted Project
fhahn requested changes to D91960: [llvm][unittests] Fix protential nullptr dereferences due to unchecked return value or EXPECT_* macro.

Marking as Request changes as there's an open suggestion by @vsk

Wed, Jan 20, 7:40 AM · Restricted Project
fhahn added a comment to D94447: [PredicateInfo] Generalize processing of conditions.

I believe compile-time is at least partly a motivation for some limitation here, but not in a way that is exposed by CTMark. I think here we mostly want to guard against the worst case (deeply nested AND/OR). Those kind of cases are not really covered by the tests in CTMark (or other parts in the test-suite), but are surprisingly common in practice (e.g. various code-generators that feed into Clang/LLVM). I think it would be desirable to have a limit on the number of items in the worklist to guard against that.

You make a good point here. I think it's worthwhile to distinguish two cases though: The first is where you have a simple chain of and's. I believe this is harmless. Even if you have 32 and's in a row, you would introduce 32 new variables, and that's linear in the input size. This is not a pathological case. The second case is where you have code like this:

%b = and i1 %a, %a
%c = and i1 %b, %b
%d = and i1 %c, %c
...

That is, where and operands get reused in a tree. In this case, my previous code introduced an exponential number of variables for %a, which is certainly not good. I have updated the implementation to add a Visited set, which will cut down the number of renames to linear. I've also added some test cases for deep chains and trees (as well as general tests for nesting).

Does this address this concern sufficiently, or do you want the linear case to be limited as well?

Wed, Jan 20, 7:37 AM · Restricted Project
fhahn accepted D94929: [docs] Fix overly specific link to uploading patches on Phabricator.

That seems indeed better, thanks! LGTM

Wed, Jan 20, 7:22 AM · Restricted Project
fhahn added inline comments to D93478: [LoopVectorizer] Fix invalid scenario that is allowed to interleave.
Wed, Jan 20, 7:04 AM · Restricted Project
fhahn added a comment to D93478: [LoopVectorizer] Fix invalid scenario that is allowed to interleave.

can you add a test case?

Wed, Jan 20, 6:58 AM · Restricted Project
fhahn added inline comments to D94996: [GVN] do not repeat PRE on failure to split critical edge.
Wed, Jan 20, 6:56 AM · Restricted Project
fhahn added a comment to D94995: Loop peeling: check that latch is conditional branch.

Could you also add the switch test case from PR48812?

Done.

Wed, Jan 20, 6:43 AM · Restricted Project
fhahn added a comment to D94708: [IR] Introduce llvm.experimental.vector.splice intrinsic.

Are there plans to use this for fixed vectors as well? If not, can this be restricted to scalable vectors only? It seems like for fixed vectors, preferring the shufflevector versions would be beneficial, to avoid having to update all transforms lookin at shuffles.

Wed, Jan 20, 6:41 AM · Restricted Project
fhahn accepted D94995: Loop peeling: check that latch is conditional branch.

LGTM, thanks! Could you also add the switch test case from PR48812?

Wed, Jan 20, 5:49 AM · Restricted Project
fhahn accepted D94547: [lld-macho] Run ObjCContractPass during LTO.

LGTM, thanks!

Wed, Jan 20, 4:06 AM · Restricted Project
fhahn added a comment to D94995: Loop peeling: check that latch is conditional branch.

Looks like this issue has also been reported in https://bugs.llvm.org/show_bug.cgi?id=48812

Wed, Jan 20, 3:56 AM · Restricted Project
fhahn committed rGeee2e8813f81: [LV] Add test cases with multiple exits which require versioning. (authored by fhahn).
[LV] Add test cases with multiple exits which require versioning.
Wed, Jan 20, 3:49 AM
fhahn added inline comments to D94995: Loop peeling: check that latch is conditional branch.
Wed, Jan 20, 2:44 AM · Restricted Project

Tue, Jan 19

fhahn added a comment to D94232: [LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands (WIP)..

Wow.
What about runtime performance, eg. mafft? No changes?

Tue, Jan 19, 6:41 AM · Restricted Project
fhahn committed rG3747b69b5312: [LoopRotate] Calls not lowered to calls should not block rotation. (authored by fhahn).
[LoopRotate] Calls not lowered to calls should not block rotation.
Tue, Jan 19, 6:38 AM
fhahn added a comment to D94230: [AArch64][SVE] Add SVE IR pass to coalesce ptrue instrinsic calls.

Thanks for the update, the new structure looks good to me. I left a few more stylistic comments, but it would be good if someone more familiar with the details of the transform would take a look as well

Tue, Jan 19, 6:27 AM · Restricted Project
fhahn committed rG83daa49758a1: [LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands. (authored by fhahn).
[LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands.
Tue, Jan 19, 2:16 AM
fhahn closed D94232: [LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands (WIP)..
Tue, Jan 19, 2:16 AM · Restricted Project
fhahn added a comment to D94232: [LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands (WIP)..

Does the same issue apply to ThinLTO?

Tue, Jan 19, 2:14 AM · Restricted Project

Mon, Jan 18

fhahn added a comment to D94892: [LV] Unconditionally branch from middle to scalar preheader if the scalar loop must execute.

This makes sense, but the fact that we need to scatter tests throughout various parts of the code seems unfortunate. I'm planning to take a closer look over the next few days to see if I can provide any ideas on how this could be improved.

Mon, Jan 18, 1:06 PM · Restricted Project
fhahn added a comment to D94687: [AArch64] Make target intrinsics DefaultAttrIntrinsics..

I also excluded the instructions in the transactional memory extension: 291ac7e622d5

Mon, Jan 18, 12:31 PM · Restricted Project
fhahn added a comment to D94447: [PredicateInfo] Generalize processing of conditions.

The thought that the current limitations are compile-time related crossed my mind, but that doesn't seem to be a concern: https://llvm-compile-time-tracker.com/compare.php?from=00f773cf424699d8eb31591fdc95e0ca18b2682c&to=10ec7c7960ea47e899003fcd7d1ba5c389ba1cae&stat=instructions

Mon, Jan 18, 12:28 PM · Restricted Project
fhahn added inline comments to D94712: Do not traverse ConstantData use-list in LoopInterchange.
Mon, Jan 18, 12:04 PM · Restricted Project
fhahn accepted D94926: [LoopInfo] Fix a typo in compareLoops.

LGTM, thanks!

Mon, Jan 18, 12:01 PM · Restricted Project
fhahn committed rG291ac7e622d5: [AArch64] Revert back to Intrinsic<> for TME instructions. (authored by fhahn).
[AArch64] Revert back to Intrinsic<> for TME instructions.
Mon, Jan 18, 10:05 AM
fhahn added a comment to D94687: [AArch64] Make target intrinsics DefaultAttrIntrinsics..

Looks like we get a lot of happiness from using these attributes. ;-)
I had a look at it before and the general direction also looked okay to me too, which I was happy to see confirmed. Therefore I am happy to accept this, even though I haven't checked all intrinsics because this is a lot of changes. So perhaps wait a day with committing in case anyone wants to have one more look.

Mon, Jan 18, 9:39 AM · Restricted Project
fhahn committed rG50ae6a3ac9bd: [AArch64] Make target intrinsics DefaultAttrIntrinsics. (authored by fhahn).
[AArch64] Make target intrinsics DefaultAttrIntrinsics.
Mon, Jan 18, 9:37 AM
fhahn closed D94687: [AArch64] Make target intrinsics DefaultAttrIntrinsics..
Mon, Jan 18, 9:37 AM · Restricted Project
fhahn committed rGa5a6164f6de5: [AArch64] Add test to check the attributes for some intrinsics. (authored by fhahn).
[AArch64] Add test to check the attributes for some intrinsics.
Mon, Jan 18, 9:19 AM
fhahn updated the diff for D94232: [LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands (WIP)..

[...]

Yes, I think the only thing outstanding with respect to testing is the omnetpp_r failure. Can you confirm if that is caused by the patch or not?

And any review of the patch would be appreciated of course!

(I thought I posted this on Friday, but looks like I forgot). The omnetpp_r crash on SPEC 2017 has not been seen again in subsequent runs so this might have been a fluke. Performance on the new runs looks fine, no change on omnetpp_r.

In term of review, could you add a test case? A -prepare-for-lto flag for loop rotate for testing purposes seems reasonable to me.

Mon, Jan 18, 9:01 AM · Restricted Project
fhahn committed rG34a2c138c896: [LoopRotate] Precommit test for prepare-for-lto handling. (authored by fhahn).
[LoopRotate] Precommit test for prepare-for-lto handling.
Mon, Jan 18, 7:25 AM
fhahn abandoned D89699: [ExtVector] Make .even/.odd/.lo/.hi return vectors for single elements..

This unfortunately breaks a bunch of existing projects. I'll abandon the change for now, as the gains are probably not worth the cost of breaking backwards compatibility.

Mon, Jan 18, 6:46 AM · Restricted Project
fhahn abandoned D59050: [InterleavedAccessAnalysis] Use unordered_map to avoid tombstone insertion..

This surfaced in more fuzzier invocations, I went ahead and submitted a fix that avoids adding empty/tombstone keys when adding new interleave group members: 83aa93e99542

Mon, Jan 18, 6:09 AM · Restricted Project
fhahn committed rGe6d758de82b6: [InferAttrs] Mark some library functions as willreturn. (authored by fhahn).
[InferAttrs] Mark some library functions as willreturn.
Mon, Jan 18, 6:05 AM
fhahn closed D94684: [InferAttrs] Mark some library functions as willreturn..
Mon, Jan 18, 6:05 AM · Restricted Project
fhahn added a comment to D94779: [Clang] Ensure vector predication pragma is ignored only when vectorization width is 1..

This ensures that the Clang loop pragma vectorize_predicate([enable|disable]) is ignored
when vectorize_width(1) is also used, since that effectively disables vectorization.

Mon, Jan 18, 3:52 AM · Restricted Project
fhahn requested review of D94905: [FuzzMutate] Add mutator to modify instruction flags..
Mon, Jan 18, 3:39 AM · Restricted Project
fhahn committed rG83aa93e99542: [VectorUtils] Do not try to add indices matching tombstone/empty values. (authored by fhahn).
[VectorUtils] Do not try to add indices matching tombstone/empty values.
Mon, Jan 18, 3:20 AM
fhahn added a comment to D93529: [AA] Store and return estimated PartialAlias offsets..

IIUC this is similar to the handling of partial overwrites in DSE (https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp#L548)?

Mon, Jan 18, 1:52 AM · Restricted Project

Sun, Jan 17

fhahn added a comment to D94232: [LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands (WIP)..

On SPEC 2017 there is still a problem with omnetpp_r (runtime error), which I'll have a look at next, but is otherwise neutral on geomean with only minor wobbles (+1%, -0.5% at most) on individual benchmarks.

With this having a substantial impact on performance, I'm quite keen to help get this in soon, ideally before the LLVM 12 branch, so please let me know if there is anything else I can do to help.

Sounds good! I think the theory behind the change should mean it should be quite safe and the data so far seems encouraging; I can confirm similar improvements for astar on our tracking.

It would probably good to get this in well ahead of the 12.0 branch, so it has a chance to make it through various downstream perf-tracking systems.

That's great! Agreed that this could do with a little soak on main before 12 branches, which IIRC is scheduled for 26 January?

Sun, Jan 17, 1:33 PM · Restricted Project
fhahn added inline comments to D93764: [LoopUnswitch] Implement first version of partial unswitching..
Sun, Jan 17, 10:36 AM · Restricted Project
fhahn updated the diff for D93764: [LoopUnswitch] Implement first version of partial unswitching..

If a dead path in a loop is unswitched into an empty loop, I suppose the idea is that LoopDeletion will later then delete it?

Sun, Jan 17, 10:34 AM · Restricted Project
fhahn added inline comments to D93789: Add accessors for MCSubtargetInfo CPU and Feature tables.
Sun, Jan 17, 6:28 AM · Restricted Project

Sat, Jan 16

fhahn added inline comments to D94547: [lld-macho] Run ObjCContractPass during LTO.
Sat, Jan 16, 8:53 AM · Restricted Project
fhahn committed rGbca16e2fbb45: [LTO] Remove options to disable inlining, vectorization & GVNLoadPRE. (authored by fhahn).
[LTO] Remove options to disable inlining, vectorization & GVNLoadPRE.
Sat, Jan 16, 8:43 AM
fhahn closed D94783: [LTO] Remove options to disable inlining and GVNLoadPRE..
Sat, Jan 16, 8:43 AM · Restricted Project
fhahn added inline comments to D94712: Do not traverse ConstantData use-list in LoopInterchange.
Sat, Jan 16, 7:24 AM · Restricted Project

Fri, Jan 15

fhahn updated the diff for D94783: [LTO] Remove options to disable inlining and GVNLoadPRE..

enable vectorization unconditionally, to be in line with the behavior in LTOBackend.cpp.

Fri, Jan 15, 9:44 AM · Restricted Project
fhahn added inline comments to D94783: [LTO] Remove options to disable inlining and GVNLoadPRE..
Fri, Jan 15, 9:42 AM · Restricted Project
fhahn added inline comments to D94547: [lld-macho] Run ObjCContractPass during LTO.
Fri, Jan 15, 9:36 AM · Restricted Project
fhahn updated the diff for D94783: [LTO] Remove options to disable inlining and GVNLoadPRE..

Agree, these should just be removed. but I also don't see any uses of disable-lto-vectorization in a test, can that and the corresponding DisableVectorization parameter be nuked as well?

Fri, Jan 15, 9:22 AM · Restricted Project
fhahn requested review of D94783: [LTO] Remove options to disable inlining and GVNLoadPRE..
Fri, Jan 15, 7:49 AM · Restricted Project
fhahn updated the diff for D94106: [Local] Treat calls that may not return as being alive (WIP)..

Happy to see this issue finally fixed :)

I think the general approach here should be more along the lines of infering WillReturn inside FuncAttrs, and then just checking the WillReturn attribute here. Especially for languages which have no forward-progress guarantee it is important that WillReturn actually gets inferred somewhere, otherwise intrinsics will be the only thing that set the attribute.

Maybe if we turn on the attributor for a few selected attributes only?

I think it would be good to approach this incrementally. So start with gradually making the behavior 'more' correct than it is at the moment, while not regressing on performance. Treating functions without side effects without mustprogress as 'alive' seems like a relatively safe thing to do as a start.

We should also improve the inference, but to make progress it might be be desirable to not predicate one on the other to start with. I realize that having good-enough inference to start with is the more principled approach and I am not sure if the desire to make progress outweighs that in the case at hand.

I like incremental improvements, but I don't think this really qualifies. What you are doing here is not making the behavior more correct while not regressing performance -- you are making it more correct while not regressing performance for languages with a forward-progress guarantee. What's likely going to happen is that this lands because it works well enough for C++, and then the remaining and technically harder part gets forgotten...

Fri, Jan 15, 6:16 AM · Restricted Project
fhahn updated the diff for D94684: [InferAttrs] Mark some library functions as willreturn..

Do not infer willreturn for __memcpy_chk.

Fri, Jan 15, 1:19 AM · Restricted Project

Thu, Jan 14

fhahn added a comment to D90328: Eliminates dead store of an exisiting value.

Compile-time: https://llvm-compile-time-tracker.com/compare.php?from=a3904cc77f181cff7355357688edfc392a236f5d&to=b5ccbbb5b1d8fc76e2291a860e4cf0a4787b77d4&stat=instructions Seems mostly fine, only outlier is kimwitu++ in NewPM-O3 configuration (k.cc has 1.25% regression).

Something I don't understand about the general approach here is why we start at the Def store and walk all uses to find a Use store to eliminate. Wouldn't it be more efficient to start at the Use store, and check the defining access? With the current approach, I think we'll only find the cases where Def is the defining access of Use, as everything else would be an indirect use. This approach should also be much easier to make more powerful (by using getClobberingMemoryAccess()) without running into compile-time issues from visiting indirect uses.

I don't remember if there was any particular reason to choose this approach to start with. I can't think of anything right now. Let me see if there are any cases that we would miss if we flip things.

Thu, Jan 14, 2:45 PM · Restricted Project
fhahn added a comment to D90328: Eliminates dead store of an exisiting value.

Compile-time: https://llvm-compile-time-tracker.com/compare.php?from=a3904cc77f181cff7355357688edfc392a236f5d&to=b5ccbbb5b1d8fc76e2291a860e4cf0a4787b77d4&stat=instructions Seems mostly fine, only outlier is kimwitu++ in NewPM-O3 configuration (k.cc has 1.25% regression).

Something I don't understand about the general approach here is why we start at the Def store and walk all uses to find a Use store to eliminate. Wouldn't it be more efficient to start at the Use store, and check the defining access? With the current approach, I think we'll only find the cases where Def is the defining access of Use, as everything else would be an indirect use. This approach should also be much easier to make more powerful (by using getClobberingMemoryAccess()) without running into compile-time issues from visiting indirect uses.

Thu, Jan 14, 2:24 PM · Restricted Project
fhahn added a comment to D94232: [LoopRotate] Add PrepareForLTO stage, avoid rotating with inline cands (WIP)..

So on SPEC 2006 this fixes astar (+9.6%) as well as shakes things up enough to "fix" h264ref (+9.0%, see D93946). Other notable changes are libquantum (+3.2%) and omnetpp (-2.8%). Geomean is +1.5%.

Thu, Jan 14, 10:35 AM · Restricted Project
fhahn added inline comments to D94633: [FunctionAttrs] Infer willreturn for functions without loops.
Thu, Jan 14, 9:50 AM · Restricted Project, Restricted Project
fhahn requested review of D94687: [AArch64] Make target intrinsics DefaultAttrIntrinsics..
Thu, Jan 14, 7:09 AM · Restricted Project
fhahn requested review of D94684: [InferAttrs] Mark some library functions as willreturn..
Thu, Jan 14, 5:59 AM · Restricted Project
fhahn committed rGc23e34e606bf: [InferFunctionAttrs] Improve CHECK variable names (NFC). (authored by fhahn).
[InferFunctionAttrs] Improve CHECK variable names (NFC).
Thu, Jan 14, 5:54 AM
fhahn accepted D90328: Eliminates dead store of an exisiting value.

I think this looks good now. I am planning to submit the patch tomorrow or so, unless there are further comments.

Thu, Jan 14, 2:35 AM · Restricted Project
fhahn updated the diff for D90328: Eliminates dead store of an exisiting value.

Updated to skip self-reads and simplified the code a bit.

Thu, Jan 14, 2:34 AM · Restricted Project
fhahn committed rG4bb11b3eafbd: [LTO] Expose opt() in LTOBackend (NFC). (authored by fhahn).
[LTO] Expose opt() in LTOBackend (NFC).
Thu, Jan 14, 2:07 AM
fhahn closed D94486: [LTO] Expose opt() in LTOBackend (NFC)..
Thu, Jan 14, 2:07 AM · Restricted Project
fhahn added inline comments to D94487: [LTO] Use lto::backend for code generation (WIP)..
Thu, Jan 14, 12:50 AM · Restricted Project
fhahn added inline comments to D94547: [lld-macho] Run ObjCContractPass during LTO.
Thu, Jan 14, 12:49 AM · Restricted Project

Wed, Jan 13

fhahn updated the diff for D90328: Eliminates dead store of an exisiting value.

reverse ping.

I think this is almost ready, it would be great to get the last remaining comments with respect to wording & tests wrapped up.

If you won't be able to follow up on this, it would be great if you could let us know, so potentially someone else could pick it up.

Sorry, still in a busy time.

I switched the name of the function to eliminateRedundantStoresOfExisitingValues. When I reverted my changes in some of the test files, one test now fails unexpectedly. The only reason those changed was because I ran that python script to update the tests.

For the additional tests, if someone else would like to pick that up, I am more than happy to go with that. I am not as well versed with my LLVM IR as many of you are :-).

Wed, Jan 13, 2:03 PM · Restricted Project
fhahn committed rG6077d55381a6: [DSE] Add tests with stores of existing values. (authored by fhahn).
[DSE] Add tests with stores of existing values.
Wed, Jan 13, 1:57 PM
fhahn added inline comments to D94630: [LTO] Add support for existing Config::Freestanding option..
Wed, Jan 13, 1:07 PM · Restricted Project
fhahn added inline comments to D94487: [LTO] Use lto::backend for code generation (WIP)..
Wed, Jan 13, 1:05 PM · Restricted Project
fhahn requested review of D94630: [LTO] Add support for existing Config::Freestanding option..
Wed, Jan 13, 1:00 PM · Restricted Project
fhahn committed rG01c3135850d1: [LTO] Add test for freestanding LTO option. (authored by fhahn).
[LTO] Add test for freestanding LTO option.
Wed, Jan 13, 12:44 PM
fhahn committed rGb7b1e8c37a92: [X86] Add tests for rv_marker lowering. (authored by fhahn).
[X86] Add tests for rv_marker lowering.
Wed, Jan 13, 6:59 AM
fhahn added a comment to D94597: [X86] Lower calls with rv_marker attribute..

I am not too familiar with how calls are handled in the X86 backend. I would really appreciate any pointers to cases that this approach might miss.

Wed, Jan 13, 6:20 AM · Restricted Project
fhahn requested review of D94597: [X86] Lower calls with rv_marker attribute..
Wed, Jan 13, 6:11 AM · Restricted Project
fhahn committed rGada96fa62179: [LTO] Add test to ensure objc-arc-contract is executed. (authored by fhahn).
[LTO] Add test to ensure objc-arc-contract is executed.
Wed, Jan 13, 4:19 AM