Page MenuHomePhabricator

hgreving (Hendrik Greving)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 31 2020, 1:07 PM (71 w, 1 d)

Recent Activity

Wed, May 26

hgreving added a comment to D98240: [VectorCombine] Simplify to scalar store if only one element updated.

For targets not supporting scalar load from vector memory (like ours), this breaks it:

%43 = load <8 x i32>, <8 x i32> addrspace(201)* %1, align 32, !tbaa !28
%44 = extractelement <8 x i32> %43, i32 0

Now:

%43 = getelementptr inbounds <8 x i32>, <8 x i32> addrspace(201)* %1, i32 0, i32 0
%44 = load i32, i32 addrspace(201)* %43, align 32

Are targets expected to provide patterns?

Interesting! I guess the code assumes that a scalar load is always possible & at least as cheap as the vector version. But I think it would make sense to ask the cost-model if that's the case. Not sure if it would be possible to test this with an in-tree target?

Wed, May 26, 7:01 AM · Restricted Project

Tue, May 25

hgreving added a comment to D98240: [VectorCombine] Simplify to scalar store if only one element updated.

For targets not supporting scalar load from vector memory (like ours), this breaks it:

Tue, May 25, 8:08 PM · Restricted Project

Fri, May 14

hgreving committed rG9d8e83b50e45: [MC] Add the ability to pass MCRegisterInfo to dump_pretty. (authored by hgreving).
[MC] Add the ability to pass MCRegisterInfo to dump_pretty.
Fri, May 14, 6:25 PM

May 13 2021

hgreving updated the summary of D102413: [MC] Add the ability to pass MCRegisterInfo to dump_pretty.
May 13 2021, 1:17 PM · Restricted Project
hgreving added reviewers for D102413: [MC] Add the ability to pass MCRegisterInfo to dump_pretty: majnemer, kariddi.
May 13 2021, 12:43 PM · Restricted Project
hgreving requested review of D102413: [MC] Add the ability to pass MCRegisterInfo to dump_pretty.
May 13 2021, 9:23 AM · Restricted Project

May 12 2021

hgreving committed rG762ac725bf97: [DAGCombiner] Fix DAG combine store elimination, different address space. (authored by hgreving).
[DAGCombiner] Fix DAG combine store elimination, different address space.
May 12 2021, 7:22 AM
hgreving committed rG4b00ffa767fc: [DAGCombiner] Add test exposing bug in DAG combine. (authored by hgreving).
[DAGCombiner] Add test exposing bug in DAG combine.
May 12 2021, 7:22 AM
hgreving closed D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 12 2021, 7:22 AM · Restricted Project
hgreving closed D102243: [DAGCombiner] Add test exposing bug in DAG combine..
May 12 2021, 7:22 AM · Restricted Project

May 11 2021

hgreving added inline comments to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 11 2021, 7:46 PM · Restricted Project
hgreving added a comment to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

Is this ok pushing? There was an open question about isNoopAddrSpaceCast(). I would suggest somebody would look at that post this patch as a possible minor improvement?

May 11 2021, 4:05 PM · Restricted Project
hgreving added inline comments to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 11 2021, 11:20 AM · Restricted Project
hgreving added a comment to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 11 2021, 10:53 AM · Restricted Project
hgreving updated the diff for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 11 2021, 10:32 AM · Restricted Project
hgreving updated the diff for D102243: [DAGCombiner] Add test exposing bug in DAG combine..
May 11 2021, 10:32 AM · Restricted Project
hgreving updated the diff for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

Fix test's comment gibberish.

May 11 2021, 10:30 AM · Restricted Project
hgreving updated the diff for D102243: [DAGCombiner] Add test exposing bug in DAG combine..

Fix test's comment gibberish.

May 11 2021, 10:30 AM · Restricted Project
hgreving added a comment to D102243: [DAGCombiner] Add test exposing bug in DAG combine..

Is there some reason to not use scripted, auto-generated CHECK lines on this file?

Would you mind hinting me to the script? I barely work upstream, sorry for that.

No problem - it's in the repo at:
utils/update_llc_test_checks.py ( https://github.com/llvm/llvm-project/blob/main/llvm/utils/update_llc_test_checks.py )

To run it, do something like this:
$ {path to}/update_llc_test_checks.py --llc={path to local}/llc dagcombine-dead-store.ll

Then, you can just run that same command after applying D102096 and rebuilding llc. No need to manually touch the test file unless it looks wrong/excessive.

I had just found it a minute before this comment. Thanks. We can use this script downstream actually. Thanks for pointing it out.

May 11 2021, 10:19 AM · Restricted Project
hgreving updated the diff for D102243: [DAGCombiner] Add test exposing bug in DAG combine..

Used update_llc_test_checks.py for CHECKs.

May 11 2021, 10:19 AM · Restricted Project
hgreving added a comment to D102243: [DAGCombiner] Add test exposing bug in DAG combine..

Is there some reason to not use scripted, auto-generated CHECK lines on this file?

Would you mind hinting me to the script? I barely work upstream, sorry for that.

No problem - it's in the repo at:
utils/update_llc_test_checks.py ( https://github.com/llvm/llvm-project/blob/main/llvm/utils/update_llc_test_checks.py )

To run it, do something like this:
$ {path to}/update_llc_test_checks.py --llc={path to local}/llc dagcombine-dead-store.ll

Then, you can just run that same command after applying D102096 and rebuilding llc. No need to manually touch the test file unless it looks wrong/excessive.

May 11 2021, 9:52 AM · Restricted Project
hgreving added a comment to D102243: [DAGCombiner] Add test exposing bug in DAG combine..

Is there some reason to not use scripted, auto-generated CHECK lines on this file?

Would you mind hinting me to the script? I barely work upstream, sorry for that.

May 11 2021, 9:51 AM · Restricted Project
hgreving updated the diff for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

Used update_llc_test_checks.py for CHECKs.

May 11 2021, 9:50 AM · Restricted Project
hgreving added a comment to D102243: [DAGCombiner] Add test exposing bug in DAG combine..

Is there some reason to not use scripted, auto-generated CHECK lines on this file?

May 11 2021, 9:24 AM · Restricted Project
hgreving added a comment to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

Code changes LG.
I'd still prefer for the tests to go in first, so we have a regression test record of the miscompiles. Let me know if the suggestion was missed or isn't clear.

I did miss this comment. Could you clarify, do you want me to commit the failing test, or a passing version with a FIXME?

@spatel meant the passing version (current trunk codegen) with a FIXME - you then rebase so this patch shows the codegen diffs - its easier to handle if you auto generate the checks with the update scripts.

Right. It would be nice to commit the baseline (current) output - it will look something like this:

define i32 @copy_fs_same() {
; CHECK-LABEL: copy_fs_same:
; CHECK:       # %bb.0:
; CHECK-NEXT:    movl 1, %eax
; CHECK-NEXT:    retl
  %t0 = load i32, i32* inttoptr (i64 1 to i32*), align 4
  store i32 %t0, i32 addrspace(257)* inttoptr (i64 1 to i32 addrspace(257)*), align 4
  ret i32 %t0
}

One more test question - is it possible to add a test that exercises the indexed address code path?
Something like this might do it?

define void @output_fs_same_indexed(i32 %v, i32* %b) {
; CHECK-LABEL: output_fs_same:
; CHECK:       # %bb.0:
; CHECK-NEXT:    movl {{[0-9]+}}(%esp), %eax
; CHECK-NEXT:    movl {{[0-9]+}}(%esp), %ecx
; CHECK-NEXT:    movl %eax, 168(%ecx)
; CHECK-NEXT:    retl
  %p = getelementptr i32, i32* %b, i64 42
  %pa = addrspacecast i32* %p to i32 addrspace(257)*
  store i32 %v, i32* %p, align 4
  store i32 %v, i32 addrspace(257)* %pa, align 4
  ret void
}
May 11 2021, 9:23 AM · Restricted Project
hgreving updated the diff for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

Removed :gs versions in the test.
Added indexed store tests.

May 11 2021, 9:20 AM · Restricted Project
hgreving updated the diff for D102243: [DAGCombiner] Add test exposing bug in DAG combine..

Removed :gs versions in the test.
Added indexed store tests.

May 11 2021, 9:20 AM · Restricted Project
hgreving added a comment to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

Code changes LG.
I'd still prefer for the tests to go in first, so we have a regression test record of the miscompiles. Let me know if the suggestion was missed or isn't clear.

I did miss this comment. Could you clarify, do you want me to commit the failing test, or a passing version with a FIXME?

@spatel meant the passing version (current trunk codegen) with a FIXME - you then rebase so this patch shows the codegen diffs - its easier to handle if you auto generate the checks with the update scripts.

Right. It would be nice to commit the baseline (current) output - it will look something like this:

define i32 @copy_fs_same() {
; CHECK-LABEL: copy_fs_same:
; CHECK:       # %bb.0:
; CHECK-NEXT:    movl 1, %eax
; CHECK-NEXT:    retl
  %t0 = load i32, i32* inttoptr (i64 1 to i32*), align 4
  store i32 %t0, i32 addrspace(257)* inttoptr (i64 1 to i32 addrspace(257)*), align 4
  ret i32 %t0
}

One more test question - is it possible to add a test that exercises the indexed address code path?
Something like this might do it?

define void @output_fs_same_indexed(i32 %v, i32* %b) {
; CHECK-LABEL: output_fs_same:
; CHECK:       # %bb.0:
; CHECK-NEXT:    movl {{[0-9]+}}(%esp), %eax
; CHECK-NEXT:    movl {{[0-9]+}}(%esp), %ecx
; CHECK-NEXT:    movl %eax, 168(%ecx)
; CHECK-NEXT:    retl
  %p = getelementptr i32, i32* %b, i64 42
  %pa = addrspacecast i32* %p to i32 addrspace(257)*
  store i32 %v, i32* %p, align 4
  store i32 %v, i32 addrspace(257)* %pa, align 4
  ret void
}
May 11 2021, 8:25 AM · Restricted Project
hgreving requested review of D102243: [DAGCombiner] Add test exposing bug in DAG combine..
May 11 2021, 7:47 AM · Restricted Project

May 10 2021

hgreving added a comment to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

Code changes LG.
I'd still prefer for the tests to go in first, so we have a regression test record of the miscompiles. Let me know if the suggestion was missed or isn't clear.

May 10 2021, 4:26 PM · Restricted Project
hgreving updated the diff for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

clang-format missed for last update.

May 10 2021, 11:34 AM · Restricted Project
hgreving added a comment to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

s/->getPointerInfo()->getAddrSpace()/->getAddressSpace()/

May 10 2021, 10:27 AM · Restricted Project
hgreving updated the diff for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

s/->getPointerInfo()->getAddrSpace()/->getAddressSpace()/

May 10 2021, 10:27 AM · Restricted Project
hgreving updated the summary of D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 10 2021, 10:07 AM · Restricted Project
hgreving added a reviewer for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space.: majnemer.
May 10 2021, 9:33 AM · Restricted Project
hgreving updated the diff for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

Extended the scope of this a little bit. The same bug was present for store to store opts as well.
Adds more tests and elaborates more in the comment.

May 10 2021, 9:32 AM · Restricted Project
hgreving added a comment to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

I've found the same bug in DAG combine, this time for store to store as somebody has already suspected above. I will add a fix + test this to this patch.

May 10 2021, 9:05 AM · Restricted Project
hgreving added a comment to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..

What about DeadStoreElimination ? It can also merge stores.. maybe dse needs similar fix.

May 10 2021, 8:31 AM · Restricted Project
hgreving added inline comments to D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 10 2021, 8:28 AM · Restricted Project
hgreving updated the diff for D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 10 2021, 8:27 AM · Restricted Project

May 7 2021

hgreving updated the summary of D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 7 2021, 4:18 PM · Restricted Project
hgreving requested review of D102096: [DAGCombiner] Fix DAG combine store elimination, different address space..
May 7 2021, 4:18 PM · Restricted Project

Nov 30 2020

hgreving committed rGd4ba5e15f4f2: Add MachineModuleInfo constructor with external MCContext (authored by hgreving).
Add MachineModuleInfo constructor with external MCContext
Nov 30 2020, 8:29 PM
hgreving closed D91313: Add MachineModuleInfo constructor with external MCContext.
Nov 30 2020, 8:28 PM · Restricted Project

Nov 20 2020

hgreving updated the diff for D91313: Add MachineModuleInfo constructor with external MCContext.
Nov 20 2020, 8:07 AM · Restricted Project

Nov 18 2020

hgreving added reviewers for D91313: Add MachineModuleInfo constructor with external MCContext: majnemer, jmolloy.
Nov 18 2020, 7:57 PM · Restricted Project
hgreving updated the diff for D91313: Add MachineModuleInfo constructor with external MCContext.

Copy constructor.

Nov 18 2020, 7:30 PM · Restricted Project

Nov 11 2020

hgreving requested review of D91313: Add MachineModuleInfo constructor with external MCContext.
Nov 11 2020, 6:03 PM · Restricted Project

Oct 16 2020

hgreving added a comment to rG0345d88de654: [NFC][ScheduleDAG] Remove unused EntrySU SUnit.

I see. Yes this seems to be just waiting for somebody else trying to remove it.

Oct 16 2020, 9:52 AM
hgreving added a comment to D87867: [NFC][ScheduleDAG] Remove unused EntrySU SUnit.

Our backend is using EntrySU the same way as described by another poster above: to add top edges to adjust for clearances to the basic block entry. When removing this, we need to add our own EntrySU, but this becomes tricky because the scheduler will try to schedule it and release the node. I think it does make sense to keep EntrySU in-tree. Thanks for that.

Oct 16 2020, 9:47 AM · Restricted Project
hgreving added a comment to rG0345d88de654: [NFC][ScheduleDAG] Remove unused EntrySU SUnit.

Is this really necessary to remove? For example, our backend is using EntrySU edges for top edges from the basic block entry, in order to account for clearances. It seems to make sense to have a node like this.

Oct 16 2020, 9:31 AM

Aug 3 2020

hgreving committed rG509f5c4ec2db: [MC] Fix memory leak when allocating MCInst with bump allocator (authored by hgreving).
[MC] Fix memory leak when allocating MCInst with bump allocator
Aug 3 2020, 4:08 PM

Jul 31 2020

hgreving added a comment to D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.

Tending to push this rel. small fix w/o an explicit Hexagon sign-off. Objections?

Jul 31 2020, 5:04 PM · Restricted Project

Jul 30 2020

hgreving updated the summary of D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.
Jul 30 2020, 10:26 AM · Restricted Project
hgreving added a comment to D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.

Done.

Jul 30 2020, 10:25 AM · Restricted Project
hgreving updated the diff for D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.
Jul 30 2020, 10:24 AM · Restricted Project

Jul 29 2020

hgreving updated the summary of D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.
Jul 29 2020, 5:52 PM · Restricted Project
hgreving added a comment to D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.

I have added some people w/o knowing them based on contributions to Hexagon and MC. Please accept or reassign the review if possible.

Jul 29 2020, 5:13 PM · Restricted Project
hgreving updated the summary of D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.
Jul 29 2020, 5:11 PM · Restricted Project
hgreving updated the summary of D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.
Jul 29 2020, 5:01 PM · Restricted Project
hgreving requested review of D84896: [MC] Fix memory leak when allocating MCInst with bump allocator.
Jul 29 2020, 4:53 PM · Restricted Project

Jul 6 2020

hgreving added a comment to D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..

In short - the virtuality is not the issue, the inheritability is. The class can be non-virtual, no problem for us. I would like to reuse existing code in the upstream pass that is currently "private". Hence, the "protected" part is important. It also makes sense generally, because a software pipeliner on a specific subtarget may follow different expansion strategies. If you would like to revert the virtuality, no problem at all, if you keep the protected inheritance. I think we should design a better defined interface for this class in the long run. Only one target upstream and us downstream are using it AFAIK, but as we are supporting more targets, we may come up with something better. SG? Can pull in Hexagon people, yes

Ah, fair enough. Thanks for explaining!

I've removed the virtual dtor and virtuality from expand in 7a99aab8692c58558b62e9a66120886b8a70fab8

Jul 6 2020, 6:42 PM · Restricted Project

Jul 2 2020

hgreving added a comment to D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..

In short - the virtuality is not the issue, the inheritability is. The class can be non-virtual, no problem for us. I would like to reuse existing code in the upstream pass that is currently "private". Hence, the "protected" part is important. It also makes sense generally, because a software pipeliner on a specific subtarget may follow different expansion strategies. If you would like to revert the virtuality, no problem at all, if you keep the protected inheritance. I think we should design a better defined interface for this class in the long run. Only one target upstream and us downstream are using it AFAIK, but as we are supporting more targets, we may come up with something better. SG? Can pull in Hexagon people, yes

Jul 2 2020, 8:31 PM · Restricted Project

Jul 1 2020

hgreving added a comment to D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..

Adding an extension point with no testing inside LLVM seems a bit problematic - is there no existing target that could use this? Or a reasonable scale of unit test that could exercise this extension point without a full-blown target?

(also this produced a warning about the fact that this type doesn't have a virtual dtor - was fixed by @jfb in c7586444ca787c3845ac4ad0bd603709f2abbb0f )

Jul 1 2020, 10:48 AM · Restricted Project

Jun 30 2020

hgreving committed rG50ac7ce94f34: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable. (authored by hgreving).
[ModuloSchedule] Make PeelingModuloScheduleExpander inheritable.
Jun 30 2020, 4:19 PM
hgreving closed D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..
Jun 30 2020, 4:19 PM · Restricted Project

Jun 26 2020

hgreving updated the summary of D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..
Jun 26 2020, 12:04 PM · Restricted Project
hgreving created D82673: [ModuloSchedule] Make PeelingModuloScheduleExpander inheritable..
Jun 26 2020, 12:02 PM · Restricted Project

Jun 8 2020

hgreving committed rGf3d8a9397003: [ModuloSchedule] Support instructions with > 1 destination when walking… (authored by hgreving).
[ModuloSchedule] Support instructions with > 1 destination when walking…
Jun 8 2020, 12:09 PM

Jun 5 2020

hgreving created D81291: [ModuloSchedule] Support instructions with > 1 destination when walking canonical use..
Jun 5 2020, 11:47 AM · Restricted Project

May 29 2020

hgreving committed rGd8f2814c9138: [ModuloSchedule] Allow illegal phis to be moved across stages. (authored by hgreving).
[ModuloSchedule] Allow illegal phis to be moved across stages.
May 29 2020, 7:34 AM

May 28 2020

hgreving edited reviewers for D80678: [ModuloSchedule] Allow illegal phis to be moved across stages., added: kariddi; removed: marcello.maggioni.
May 28 2020, 9:49 AM · Restricted Project

May 27 2020

hgreving added a reviewer for D80678: [ModuloSchedule] Allow illegal phis to be moved across stages.: marcello.maggioni.
May 27 2020, 6:02 PM · Restricted Project
hgreving created D80678: [ModuloSchedule] Allow illegal phis to be moved across stages..
May 27 2020, 5:29 PM · Restricted Project
hgreving retitled D80678: [ModuloSchedule] Allow illegal phis to be moved across stages. from ModuloSchedule] Allow illegal phis to be moved across stages. to [ModuloSchedule] Allow illegal phis to be moved across stages..
May 27 2020, 5:29 PM · Restricted Project

May 21 2020

hgreving committed rG8a6a2c4cb66d: [ModuloSchedule] Add missing comma. (authored by hgreving).
[ModuloSchedule] Add missing comma.
May 21 2020, 1:33 PM

May 20 2020

hgreving accepted D79112: [SelectionDAG] Add the option of disabling generic combines..

LGTM!

May 20 2020, 2:54 PM · Restricted Project
hgreving added a comment to D79112: [SelectionDAG] Add the option of disabling generic combines..

nit: s/ didn't make any effect./ didn't have any effect./

May 20 2020, 2:53 PM · Restricted Project

May 15 2020

hgreving added a comment to D80027: Trivial fix for instruction with more than one destination in modulo peeler..

Thanks

May 15 2020, 12:31 PM · Restricted Project
hgreving created D80027: Trivial fix for instruction with more than one destination in modulo peeler..
May 15 2020, 12:31 PM · Restricted Project

May 7 2020

hgreving accepted D79581: [ModuloSchedule] Fix epilogue peeling with illegal phi..

LGTM!

May 7 2020, 9:05 AM · Restricted Project

Apr 16 2020

hgreving added a comment to D78175: [MachineDCE] Predicated instructions shouldn't clear LivePhysRegs..

LGTM

Apr 16 2020, 7:48 AM · Restricted Project
hgreving requested changes to D78175: [MachineDCE] Predicated instructions shouldn't clear LivePhysRegs..

s/kill the registers they right/kill the registers they write/

Apr 16 2020, 7:48 AM · Restricted Project

Apr 1 2020

hgreving added a comment to D74183: [IRGen] Add an alignment attribute to underaligned sret parameters.

If it's just tramp3d-v4, I'm not that concerned... but that's a weird result. On x86 in particular, alignment markings have almost no effect on optimization, generally.

I've just looked at the IR diff for tramp3d-v4 and it turns out that the root cause is an old friend of mine: The insertion of alignment assumptions during inlining (https://github.com/llvm/llvm-project/blob/b58902bc72c2b479b5ed27ec0d3422ba9782edbb/llvm/lib/Transforms/Utils/InlineFunction.cpp#L1139-L1173). That is, the IR now contains many instances of this sequence:

%ptrint = ptrtoint %class.GuardLayers* %guards_m to i64
%maskedptr = and i64 %ptrint, 3
%maskcond = icmp eq i64 %maskedptr, 0
tail call void @llvm.assume(i1 %maskcond)

to preserve the alignment information. From a cursory look I cannot tell whether these additional assumes also regress optimization (due to multi-use), but given the size increase on the final binary it seems pretty likely that this is the case.

This preservation of alignment during inlining is the reason why we used to not emit alignment information for pointer arguments in Rust for a long time: It caused serious regressions in optimization and increased compile-time. Nowadays we do emit alignment information, but set -preserve-alignment-assumptions-during-inlining=false to prevent this inlining behavior.

I think for the purposes of this revision, this means that we should probably either a) default preserve-alignment-assumptions-during-inlining to false (I would prefer this) or b) not emit the alignment unless it is smaller than the ABI alignment (I guess this was what this patch originally did?)

Apr 1 2020, 4:54 PM · Restricted Project

Feb 3 2020

hgreving added inline comments to D73804: [GVN] Add GVNOption to control load-pre more fine-grained..
Feb 3 2020, 3:24 PM · Restricted Project
hgreving updated the diff for D73804: [GVN] Add GVNOption to control load-pre more fine-grained..

llvm/test/Transforms/GVN/PRE/pre-load-in-loop.ll:
s/Should only be one load in the loop./Both loads should remain in the loop./

Feb 3 2020, 3:16 PM · Restricted Project
hgreving added inline comments to D73804: [GVN] Add GVNOption to control load-pre more fine-grained..
Feb 3 2020, 2:53 PM · Restricted Project
hgreving added inline comments to D73804: [GVN] Add GVNOption to control load-pre more fine-grained..
Feb 3 2020, 7:43 AM · Restricted Project

Jan 31 2020

hgreving added inline comments to D73804: [GVN] Add GVNOption to control load-pre more fine-grained..
Jan 31 2020, 2:35 PM · Restricted Project
hgreving added a comment to D73804: [GVN] Add GVNOption to control load-pre more fine-grained..

Hello, this switch intends to help our backend to software pipeline single basic block loops. The suppressed GVN opt is creating control flow in loops which we like to avoid. Thanks in advance for looking at the patch.

Jan 31 2020, 1:39 PM · Restricted Project
hgreving created D73804: [GVN] Add GVNOption to control load-pre more fine-grained..
Jan 31 2020, 1:30 PM · Restricted Project