Page MenuHomePhabricator

labrinea (Alexandros Lamprineas)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 10 2015, 2:25 AM (226 w, 5 d)

Recent Activity

Sun, Sep 29

labrinea added a comment to D68050: WIP Make attribute target work better with AArch64.

ARM and AArch64 have a way to list the implied target features using the TargetParser but we can't directly use that in CodeGenModule because it's tied to the backend.

Sun, Sep 29, 3:55 PM · Restricted Project

Fri, Sep 27

labrinea added a comment to D68050: WIP Make attribute target work better with AArch64.

However, passing the AArch64 architecture names in target-cpu isn't supported by LLVM

The Clang documentation suggests that arch is used to override the CPU, not the Architecture (which is rather confusing if you ask me). GCC makes more sense having separate target attributes for CPU and Architecture (see the equivalent GCC documentation). I think target-cpu should remain generic when it is not explicitly specified either on the command line (-mcpu) or as a function attribute (i.e target("arch=cortex-a57")). However, if the function attribute specifies an Architecture (i.e target("arch=armv8.4a")), I agree we should favor the subtarget features corresponding to armv8.4 over those of the command line. Similarly we should favor the subtarget features corresponding to cortex-a57 (not sure if we do so atm - I think we don't). ARM and AArch64 have a way to list the implied target features using the TargetParser but we can't directly use that in CodeGenModule because it's tied to the backend.

Fri, Sep 27, 10:30 AM · Restricted Project
labrinea committed rGc006b6f4cb80: [MC][ARM] vscclrm disassembles as vldmia (authored by labrinea).
[MC][ARM] vscclrm disassembles as vldmia
Fri, Sep 27, 1:23 AM

Thu, Sep 26

labrinea updated the diff for D68025: [MC][ARM] vscclrm disassembles as vldmia.

Updated the Filecheck labels as suggested.

Thu, Sep 26, 10:15 AM · Restricted Project
labrinea added inline comments to D68025: [MC][ARM] vscclrm disassembles as vldmia.
Thu, Sep 26, 10:06 AM · Restricted Project

Wed, Sep 25

labrinea created D68025: [MC][ARM] vscclrm disassembles as vldmia.
Wed, Sep 25, 7:24 AM · Restricted Project

Mon, Sep 23

labrinea added a reviewer for D67485: AArch64: use ldp/stp for atomic & volatile 128-bit where appropriate.: labrinea.
Mon, Sep 23, 9:29 AM · Restricted Project
labrinea added a comment to D67485: AArch64: use ldp/stp for atomic & volatile 128-bit where appropriate..

I think Clang is involved there too, in horribly non-obvious ways (for example I think that's the only way to get the actual libcalls you want rather than legacy ones). Either way, that's a change that would need pretty careful coordination. Since all of our CPUs are Cyclone or above we could probably just skip the libcalls entirely at Apple without ABI breakage (which, unintentionally, is what this patch does).

I am not sure I am following here. According to https://llvm.org/docs/Atomics.html the AtomicExpandPass will translate atomic operations on data sizes above MaxAtomicSizeInBitsSupported into calls to atomic libcalls. The docs say that even though the libcalls share the same names with clang builtins they are not directly related to them. Indeed, I hacked the AArhc64 backend to disallow codegen for 128-bit atomics and as a result LLVM emitted calls to __atomic_store_16 and __atomic_load_16. Are those legacy names? I also tried emitting IR for the clang builtins and I saw atomic load/store IR instructions (like those in your tests), no libcalls. Anyhow, my concern here is that if sometime in the future we replace the broken CAS loop with a libcall, the current patch will break ABI compatibity between v8.4 objects with atomic ldp/stp and v8.X objects without the extension. Moreover, this ABI incompatibility already exists between objects built with LLVM and GCC. Any thoughts?

Mon, Sep 23, 9:29 AM · Restricted Project

Fri, Sep 20

labrinea added a comment to D67485: AArch64: use ldp/stp for atomic & volatile 128-bit where appropriate..

Hi Tim, thanks for looking into this optimization opportunity. I have a few remarks regarding this change:

  • First, it appears that the current codegen (CAS loop) for 128-bit atomic accesses is broken based on this comment: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814#c3. There are two problematic cases as far as I understand: (1) const and (2) volatile atomic objects. Const objects disallow write access to the underlying memory, volatile objects mandate that each byte of the underlying memory shall be accessed exactly once according to the AAPCS. The CAS loop violates both.
Fri, Sep 20, 5:28 AM · Restricted Project

Jul 14 2019

labrinea committed rG951bb68ce262: [TargetParser][ARM] Account dependencies when processing target features (authored by labrinea).
[TargetParser][ARM] Account dependencies when processing target features
Jul 14 2019, 1:35 PM
labrinea committed rG24cacf9c56f0: [clang][Driver][ARM] Favor -mfpu over default CPU features (authored by labrinea).
[clang][Driver][ARM] Favor -mfpu over default CPU features
Jul 14 2019, 11:34 AM

Jul 4 2019

labrinea requested review of D64048: [TargetParser][ARM] Account dependencies when processing target features.
Jul 4 2019, 7:57 AM · Restricted Project, Restricted Project
labrinea updated the diff for D64048: [TargetParser][ARM] Account dependencies when processing target features.

Added the dependency of mve on dsp and some missing tests to cover those cases.

Jul 4 2019, 3:29 AM · Restricted Project, Restricted Project
labrinea added inline comments to D63936: [clang][Driver][ARM] Favor -mfpu over default CPU features.
Jul 4 2019, 3:07 AM · Restricted Project, Restricted Project

Jul 3 2019

labrinea added inline comments to D63936: [clang][Driver][ARM] Favor -mfpu over default CPU features.
Jul 3 2019, 5:58 AM · Restricted Project, Restricted Project

Jul 2 2019

labrinea committed rG9fcf5dadd7cc: [clang][Driver][ARM] NFC: Remove unused function parameter (authored by labrinea).
[clang][Driver][ARM] NFC: Remove unused function parameter
Jul 2 2019, 2:47 AM

Jul 1 2019

labrinea created D64048: [TargetParser][ARM] Account dependencies when processing target features.
Jul 1 2019, 5:08 PM · Restricted Project, Restricted Project
labrinea updated the diff for D63936: [clang][Driver][ARM] Favor -mfpu over default CPU features.

I've split the patch.

Jul 1 2019, 4:27 PM · Restricted Project, Restricted Project
labrinea retitled D63936: [clang][Driver][ARM] Favor -mfpu over default CPU features from [ARM] Minor fixes in command line option parsing to [clang][Driver][ARM] Favor -mfpu over default CPU features.
Jul 1 2019, 4:25 PM · Restricted Project, Restricted Project
labrinea created D64044: [clang][Driver][ARM] NFC: Remove unused function parameter.
Jul 1 2019, 3:49 PM · Restricted Project, Restricted Project
labrinea added a comment to D63936: [clang][Driver][ARM] Favor -mfpu over default CPU features.

@simon_tatham, thanks for clarifying. I think my change is doing the right thing then: favors the -mfpu option over the default CPU features. I will split the patch as @ostannard suggested.

Jul 1 2019, 9:40 AM · Restricted Project, Restricted Project
labrinea added a comment to D63936: [clang][Driver][ARM] Favor -mfpu over default CPU features.

The second change this patch makes

Could this be spilt into two patches?

Jul 1 2019, 9:02 AM · Restricted Project, Restricted Project
labrinea added reviewers for D63936: [clang][Driver][ARM] Favor -mfpu over default CPU features: llvm-commits, cfe-commits.
Jul 1 2019, 2:17 AM · Restricted Project, Restricted Project

Jun 28 2019

labrinea created D63936: [clang][Driver][ARM] Favor -mfpu over default CPU features.
Jun 28 2019, 9:13 AM · Restricted Project, Restricted Project

Dec 17 2018

labrinea closed D55108: [AArch64] Re-run load/store optimizer after aggressive tail duplication.

Committed as https://reviews.llvm.org/rL349338

Dec 17 2018, 2:57 AM
labrinea added a comment to D55108: [AArch64] Re-run load/store optimizer after aggressive tail duplication.

IIRC, there is a test for the pass pipeline I would expect needs updating.

Dec 17 2018, 2:48 AM

Dec 12 2018

labrinea added a comment to D55108: [AArch64] Re-run load/store optimizer after aggressive tail duplication.

I've tested the patch with native builds of the llvm-test-suite on an AArch64 Cortex-A72 and couldn't spot anything interesting in terms of compilation time.

Dec 12 2018, 7:23 AM

Dec 11 2018

labrinea added a comment to D55108: [AArch64] Re-run load/store optimizer after aggressive tail duplication.

Ping

Dec 11 2018, 9:50 AM

Dec 4 2018

labrinea added inline comments to D55009: [GVN] Don't perform scalar PRE on GEPs.
Dec 4 2018, 9:07 AM

Nov 30 2018

labrinea updated subscribers of D55108: [AArch64] Re-run load/store optimizer after aggressive tail duplication.
Nov 30 2018, 7:09 AM
labrinea updated subscribers of D55009: [GVN] Don't perform scalar PRE on GEPs.
Nov 30 2018, 7:09 AM
labrinea accepted D55112: [ARM] FP16: select vld1.16 for vector loads with post-increment.

Looks fine. Thanks!

Nov 30 2018, 6:16 AM
labrinea edited reviewers for D55009: [GVN] Don't perform scalar PRE on GEPs, added: t.p.northover, john.brawn; removed: llvm-commits.
Nov 30 2018, 3:55 AM
labrinea added a comment to D55009: [GVN] Don't perform scalar PRE on GEPs.

It may be worthwhile allowing scalar PRE on GEPs that we know won't be combined into the addressing mode of a load/store, i.e. those where TargetTransformInfo::isLegalAddressingMode returns false.

Nov 30 2018, 3:50 AM
labrinea created D55108: [AArch64] Re-run load/store optimizer after aggressive tail duplication.
Nov 30 2018, 1:55 AM

Nov 28 2018

labrinea created D55009: [GVN] Don't perform scalar PRE on GEPs.
Nov 28 2018, 9:31 AM

Nov 13 2018

Herald updated subscribers of D32140: Global code motion of congruent computations.
Nov 13 2018, 7:15 AM · Restricted Project

Nov 6 2018

labrinea added a comment to D54170: [InstCombine][SelectionDAG][AArch64] fold gep into select to enable speculation of load.

This looks like a bunch of separate changes which should be split into multiple patches. Especially the changes to DAGCombine and InstCombiner::visitZExt .

Nov 6 2018, 12:54 PM
labrinea added a comment to D53236: [SelectionDAG] swap select_cc operands to enable folding.

LGTM

(For reference: I was wondering why x86 doesn't show any diffs for this change; it looks like there's custom code in X86ISelLowering that already does the same thing.)

Nov 6 2018, 12:43 PM
labrinea created D54170: [InstCombine][SelectionDAG][AArch64] fold gep into select to enable speculation of load.
Nov 6 2018, 11:40 AM

Nov 2 2018

labrinea updated the diff for D53236: [SelectionDAG] swap select_cc operands to enable folding.

Rebased and clang-formatted.

Nov 2 2018, 8:01 AM

Oct 29 2018

labrinea added inline comments to D53236: [SelectionDAG] swap select_cc operands to enable folding.
Oct 29 2018, 5:36 AM
labrinea updated the diff for D53236: [SelectionDAG] swap select_cc operands to enable folding.

I've autogenerated the filecheck lines to show the diff compared to the trunk codegen. For making sure we never fall-through to the next block, having changed the CC but not swapped (N2, N3), I've moved all the preconditions to the beginning of the block (instead of moving the block into a helper function).

Oct 29 2018, 5:32 AM

Oct 24 2018

labrinea added a comment to D53236: [SelectionDAG] swap select_cc operands to enable folding.

Is the motivating case integer or FP?
I'm asking because we have a canonicalization for integer cmp+sel for the IR in these tests, but we're missing the corresponding FP transform.
If we add the FP canonicalization in IR, would there still be a need for this backend patch? Ie, is something generating this select code in the DAG itself?

Oct 24 2018, 6:10 PM

Oct 15 2018

labrinea added a reviewer for D53236: [SelectionDAG] swap select_cc operands to enable folding: spatel.
Oct 15 2018, 2:49 AM

Oct 12 2018

labrinea created D53236: [SelectionDAG] swap select_cc operands to enable folding.
Oct 12 2018, 6:40 PM

Sep 26 2018

labrinea planned changes to D52568: [InstCombine] Delay Phi operand folding in the pass manager.

Not ready for review. Using this as reference to and RFC in llvm-dev.

Sep 26 2018, 11:52 AM
labrinea created D52568: [InstCombine] Delay Phi operand folding in the pass manager.
Sep 26 2018, 11:49 AM

Sep 12 2018

labrinea created D51980: [GVNHoist] computeInsertionPoints() miscalculates the Iterated Dominance Frontiers.
Sep 12 2018, 5:52 AM

Sep 7 2018

labrinea added reviewers for D51801: [MemorySSAUpdater] Avoid creating self-referencing MemoryDefs: efriedma, george.burgess.iv.
Sep 7 2018, 11:03 AM
labrinea added inline comments to D51801: [MemorySSAUpdater] Avoid creating self-referencing MemoryDefs.
Sep 7 2018, 10:49 AM
labrinea created D51801: [MemorySSAUpdater] Avoid creating self-referencing MemoryDefs.
Sep 7 2018, 10:37 AM

Aug 28 2018

labrinea requested review of D49858: [RFC] re-enable GVNHoist by default.
Aug 28 2018, 6:29 AM
labrinea updated the diff for D49858: [RFC] re-enable GVNHoist by default.

Rebase rL338240 since the excessive memory usage observed when using GVNHoist with UBSan has been fixed by rL340818 (https://reviews.llvm.org/D50323).

Aug 28 2018, 6:29 AM
labrinea added a comment to D50323: [GVNHoist] Prune out useless CHI insertions.

Do you need help with pushing the changes?

Apologies for delaying this, I was out of office. I'll rebase and push it asap.

Aug 28 2018, 2:07 AM

Aug 10 2018

labrinea added inline comments to D50323: [GVNHoist] Prune out useless CHI insertions.
Aug 10 2018, 5:42 AM
labrinea added inline comments to D50323: [GVNHoist] Prune out useless CHI insertions.
Aug 10 2018, 5:30 AM

Aug 9 2018

labrinea added a comment to D50323: [GVNHoist] Prune out useless CHI insertions.

So, is everyone happy with this change?

Aug 9 2018, 1:36 AM

Aug 7 2018

labrinea added inline comments to D50323: [GVNHoist] Prune out useless CHI insertions.
Aug 7 2018, 3:07 AM

Aug 6 2018

labrinea added inline comments to D50323: [GVNHoist] Prune out useless CHI insertions.
Aug 6 2018, 6:28 AM
labrinea planned changes to D49858: [RFC] re-enable GVNHoist by default.
Aug 6 2018, 3:11 AM
labrinea reopened D49858: [RFC] re-enable GVNHoist by default.

This got reverted because of an out-of-memory error on an ubsan buildbot. Details and fix here -> https://reviews.llvm.org/D50323. I'll update the tests upon rebase.

Aug 6 2018, 3:10 AM
labrinea created D50323: [GVNHoist] Prune out useless CHI insertions.
Aug 6 2018, 1:46 AM

Jul 30 2018

labrinea added a comment to D49858: [RFC] re-enable GVNHoist by default.

Did you test it with some benchmarks? Results?

I am running lnt, spec2000 and spec2006 on AArch64 at the moment. I'll post results soon.

Jul 30 2018, 3:14 AM

Jul 26 2018

labrinea created D49858: [RFC] re-enable GVNHoist by default.
Jul 26 2018, 8:30 AM

Jul 23 2018

labrinea added inline comments to D49229: [AggressiveInstCombine] Fold redundant masking operations of shifted value.
Jul 23 2018, 7:38 AM
labrinea added a reviewer for D49229: [AggressiveInstCombine] Fold redundant masking operations of shifted value: labrinea.
Jul 23 2018, 7:11 AM
labrinea added inline comments to D49229: [AggressiveInstCombine] Fold redundant masking operations of shifted value.
Jul 23 2018, 7:10 AM

Jul 20 2018

labrinea updated the diff for D49425: [MemorySSAUpdater] Update Phi operands after trivial Phi elimination.

Changes to prior revision.

  • Removed the update loop for PhiOps and used TrackingVH<MemoryAccess> instead.
  • Replaced the Bitcode reproducer with IR using -preserve-ll-uselistorder.
Jul 20 2018, 3:59 AM

Jul 19 2018

labrinea added a comment to D49425: [MemorySSAUpdater] Update Phi operands after trivial Phi elimination.

If the bitcode is crashing but the textual IR isn't, you're probably getting bitten by use-list ordering. You can use the preserve-ll-uselistorder option for "opt" to preserve it in IR.

Jul 19 2018, 9:46 AM
labrinea created D49555: [GVNHoist] safeToHoistLdSt incorrectly checks whether a defining access dominates the insertion point.
Jul 19 2018, 9:40 AM

Jul 18 2018

labrinea added a comment to D49425: [MemorySSAUpdater] Update Phi operands after trivial Phi elimination.

Does the original test-case crash reliably as IR for you? If so, please use that instead. (Phab won't let me download the attached bitcode, but with asan, I see use-after-free crashes 100% of the time in the original repro).

It does, but using opt -S -O3 ./tc_memphi_gvnhoist.ll -enable-gvn-hoist. Using bugpoint on that command you get the bitcode I uploaded.

Jul 18 2018, 3:05 AM

Jul 17 2018

labrinea added a comment to D49425: [MemorySSAUpdater] Update Phi operands after trivial Phi elimination.

A few remarks:

  • SmallVector<WeakVH, 8> PhiOps fixes the bug on its own (without the rest changes) and I am wondering why..
  • When we mark a block as visited why do we cache it? When the recursion ends we might trivially remove the Phi. In that case the second cache insertion for the same key block should fail, no?
  • Do we ever reach the PHIExistsButNeedsUpdate case? Is it when a Phi existed beforehand, meaning we did not create it? I can't think of another way to reach that state.
  • Interestingly enough the reproducer only made opt crash in bitcode form and not in IR form.
Jul 17 2018, 7:16 AM
labrinea created D49425: [MemorySSAUpdater] Update Phi operands after trivial Phi elimination.
Jul 17 2018, 7:08 AM

Jul 13 2018

labrinea updated the diff for D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.

Ok, I've convinced myself that using WeakVH is the most straightforward fix for now. We shouldn't be spending more time on this.

Jul 13 2018, 5:04 AM

Jul 12 2018

labrinea added a comment to D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.

Replacing MemoryPhi * with WeakVH won't work out of the box; it requires typecasts and null checks upon iteration. It also adds and additional overhead (similar to AssertingVH though). In general, the idea of keeping null references in the ADT instead of actually deleting them seems like a workaround to me. I don't see why we should be afraid of making non trivial changes in the code if there's a fundamental bug. On that note I still believe the line 303 of the original revision is wrong since we push_back() when adding new elements:

FixupList.append(InsertedPHIs.end() - StartingPHISize, InsertedPHIs.end());

Shouldn't it be like this?

FixupList.append(InsertedPHIs.begin() + StartingPHISize, InsertedPHIs.end());

Answering some inline comments:

Jul 12 2018, 10:23 AM

Jul 10 2018

labrinea updated the diff for D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.

Changes to the prior revision:

  • I've used std::set for InsertedPHIs to avoid linear cost lookups upon deletion.
  • I've refactored insertDef() so that it no longer relies on insertion order iteration over InsertedPHIs.
Jul 10 2018, 10:41 AM
labrinea added a comment to D49030: Add OrderedSet, with constant-time insertion and removal, and random access iteration..

Personally, I'd be in favour of changing MapVector to just do this, since it already has an index. I'd also be in favour of adding an index to SetVector to match. There'd be some work to do in auditing/updating users, but I doubt there are many calls to erase() and I'm skeptical that anyone relies on the current order for something other than determinism.

I think we should not change MapVector. Its underlying data structure is a vector with <key,value> pairs but we only need to store a single value. Moreover, both MapVector and SetVector provide insertion order iteration and their users might rely on that. I am not sure we should change that. SmallSet might be a good alternative for lower insertion/deletion complexity, but at the moment it does not provide iteration over the underlying data structures. It uses a SmallVector for small data sets and expands it to an std::set if it grows too much. Is there a way to abstract those underlying iterators? If not I think we should keep this new ADT and rename/document it properly.

Jul 10 2018, 2:18 AM

Jul 8 2018

labrinea added inline comments to D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.
Jul 8 2018, 4:07 PM

Jul 7 2018

labrinea added a comment to D49030: Add OrderedSet, with constant-time insertion and removal, and random access iteration..

We already have SetVector which is widely used for these patterns. If we need both, we need a clear explanation of the difference and why we need both (IE, why users of one can't use the other).

The remove operation on a SetVector can cost linear time and this might be an issue in some cases. Please have a look at the review comments of https://reviews.llvm.org/D48372

Jul 7 2018, 6:32 AM

Jul 6 2018

labrinea updated the diff for D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.

Added back the header file for SmallPtrSet that was accidentally removed.

Jul 6 2018, 9:32 AM
labrinea updated the diff for D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.

Used the ADT from https://reviews.llvm.org/D49030

Jul 6 2018, 9:28 AM
labrinea added a child revision for D49030: Add OrderedSet, with constant-time insertion and removal, and random access iteration.: D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.
Jul 6 2018, 8:59 AM
labrinea added a parent revision for D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset: D49030: Add OrderedSet, with constant-time insertion and removal, and random access iteration..
Jul 6 2018, 8:59 AM
labrinea added a comment to D48504: [WIP] Add InsertionOrderSet, with constant-time insertion and removal..

I've accidentally edited the revision instead of just adding a new diff. Anyway, I've reset it to the original content and created https://reviews.llvm.org/D49030 with my changes for review.

Jul 6 2018, 8:54 AM
labrinea retitled D48504: [WIP] Add InsertionOrderSet, with constant-time insertion and removal. from Add OrderedSet, with constant-time insertion and removal, and random access iteration. to [WIP] Add InsertionOrderSet, with constant-time insertion and removal..
Jul 6 2018, 8:51 AM
labrinea created D49030: Add OrderedSet, with constant-time insertion and removal, and random access iteration..
Jul 6 2018, 8:44 AM
labrinea retitled D48504: [WIP] Add InsertionOrderSet, with constant-time insertion and removal. from [WIP] Add InsertionOrderSet, with constant-time insertion and removal. to Add OrderedSet, with constant-time insertion and removal, and random access iteration..
Jul 6 2018, 8:41 AM

Jun 26 2018

labrinea added a comment to D48504: [WIP] Add InsertionOrderSet, with constant-time insertion and removal..

Another thing to consider maybe is the complexity of iteration over the vector. Imagine the case where we insert N elements and we erase M with M being almost the size of N. The iteration will be O(N) and not O(N-M).

Jun 26 2018, 2:48 AM

Jun 25 2018

labrinea added a comment to D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.
Jun 25 2018, 3:39 AM
labrinea added inline comments to D48504: [WIP] Add InsertionOrderSet, with constant-time insertion and removal..
Jun 25 2018, 3:27 AM

Jun 22 2018

labrinea added inline comments to D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.
Jun 22 2018, 6:40 AM

Jun 21 2018

labrinea added inline comments to D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.
Jun 21 2018, 1:49 AM

Jun 20 2018

labrinea created D48372: [MemorySSAUpdater] Remove deleted trivial Phis from active workset.
Jun 20 2018, 8:27 AM

Jun 13 2018

labrinea added a comment to D48122: [SimplifyCFG] Hoist common if-then-else code if used by two-entry PHI nodes.

My argument would be that this change is fairly small. To be honest I don't know what is the status of GVN-Hoist. If it is in a good shape, then enabling it is the best way to go. If there are a few bugs to fix I am happy to help, but if it is far from being in a good shape then a workaround like this should be acceptable.

Jun 13 2018, 8:50 AM
labrinea created D48122: [SimplifyCFG] Hoist common if-then-else code if used by two-entry PHI nodes.
Jun 13 2018, 6:34 AM

May 30 2018

labrinea updated the diff for D46273: [InstCombine, ARM] Convert vld1 to llvm load.

Bail the optimization if the memory alignment is not power of two. Added a test to cover this case.

May 30 2018, 5:39 AM

May 22 2018

labrinea updated the diff for D46133: [InstCombine, ARM, AArch64] Convert table lookup to shuffle vector.
  • Restrict the optimization to table lookups returning a <8 x i8> vector type. It's only beneficial for the mask {7,6,5,4,3,2,1,0} anyway.
  • Bail out if the constant mask contains an index out of range. The second argument of the new shufflevector is always going to be <undef> so the range is [0 ~ NumElts-1], not [0 ~ 2*NumElts-1], like @efriedma noticed.
  • Replaced getZExtValue() with getLimitedValue() for getting the value of a ConstantInt.
  • Simplified the retrieval of mask indices by using ConstantDataVector::get instead of ConstantVector::get.
  • Added testcases where the transform bails out.
  • Autogenerated the Filecheck patterns using the script utils/update_test_checks.py
May 22 2018, 8:27 AM
labrinea updated the diff for D46273: [InstCombine, ARM] Convert vld1 to llvm load.

Using getLimitedValue() instead of getZExtValue() for the ConstantInt representing the memory alignment of the load instruction. Updated the tests: alignment in now expressed in bytes instead of bits.

May 22 2018, 2:49 AM

May 17 2018

labrinea added a comment to D46273: [InstCombine, ARM] Convert vld1 to llvm load.

Ping?

May 17 2018, 1:35 AM