Page MenuHomePhabricator

[AArch64] Teach Load/Store optimizier to rename store operands for pairing.
ClosedPublic

Authored by fhahn on Nov 19 2019, 9:00 AM.

Details

Summary

In some cases, we can rename a store operand, in order to enable pairing
of stores. For store pairs, that cannot be merged because the first
tored register is defined in between the second store, we try to find
suitable rename register.

First, we check if we can rename the given register:

  1. The first store register must be killed at the store, which means we do not have to rename instructions after the first store.
  2. We scan backwards from the first store, to find the definition of the stored register and check all uses in between are renamable. Along they way, we collect the minimal register classes of the uses for overlapping (sub/super)registers.

Second, we try to find an available register from the minimal physical
register class of the original register. A suitable register must not be

  1. defined before FirstMI
  2. between the previous definition of the register to rename
  3. a callee saved register.

We use KILL flags to clear defined registers while scanning from the
beginning to the end of the block.

This triggers quite often, here are the top changes for MultiSource,
SPEC2000, SPEC2006 compiled with -O3 for iOS:

Metric: aarch64-ldst-opt.NumPairCreated

Program base patch diff
test-suite...nch/fourinarow/fourinarow.test 2.00 39.00 1850.0%
test-suite...s/ASC_Sequoia/IRSmk/IRSmk.test 46.00 80.00 73.9%
test-suite...chmarks/Olden/power/power.test 70.00 96.00 37.1%
test-suite...cations/hexxagon/hexxagon.test 29.00 39.00 34.5%
test-suite...nchmarks/McCat/05-eks/eks.test 100.00 132.00 32.0%
test-suite.../Trimaran/enc-rc4/enc-rc4.test 46.00 59.00 28.3%
test-suite...T2006/473.astar/473.astar.test 160.00 200.00 25.0%
test-suite.../Trimaran/enc-md5/enc-md5.test 8.00 10.00 25.0%
test-suite...telecomm-gsm/telecomm-gsm.test 113.00 139.00 23.0%
test-suite...ediabench/gsm/toast/toast.test 113.00 139.00 23.0%
test-suite...Source/Benchmarks/sim/sim.test 91.00 111.00 22.0%
test-suite...C/CFP2000/179.art/179.art.test 41.00 49.00 19.5%
test-suite...peg2/mpeg2dec/mpeg2decode.test 245.00 279.00 13.9%
test-suite...marks/Olden/health/health.test 16.00 18.00 12.5%
test-suite...ks/Prolangs-C/cdecl/cdecl.test 90.00 101.00 12.2%
test-suite...fice-ispell/office-ispell.test 91.00 100.00 9.9%
test-suite...oxyApps-C/miniGMG/miniGMG.test 430.00 465.00 8.1%
test-suite...lowfish/security-blowfish.test 39.00 42.00 7.7%
test-suite.../Applications/spiff/spiff.test 42.00 45.00 7.1%
test-suite...arks/mafft/pairlocalalign.test 2473.00 2646.00 7.0%
test-suite.../VersaBench/ecbdes/ecbdes.test 29.00 31.00 6.9%
test-suite...nch/beamformer/beamformer.test 220.00 235.00 6.8%
test-suite...CFP2000/177.mesa/177.mesa.test 2110.00 2252.00 6.7%
test-suite...ve-susan/automotive-susan.test 109.00 116.00 6.4%
test-suite...s-C/unix-smail/unix-smail.test 65.00 69.00 6.2%
test-suite...CI_Purple/SMG2000/smg2000.test 1194.00 1265.00 5.9%
test-suite.../Benchmarks/nbench/nbench.test 472.00 500.00 5.9%
test-suite...oxyApps-C/miniAMR/miniAMR.test 248.00 262.00 5.6%
test-suite...quoia/CrystalMk/CrystalMk.test 18.00 19.00 5.6%
test-suite...rks/tramp3d-v4/tramp3d-v4.test 7331.00 7710.00 5.2%
test-suite.../Benchmarks/Bullet/bullet.test 5651.00 5938.00 5.1%
test-suite...ternal/HMMER/hmmcalibrate.test 750.00 788.00 5.1%
test-suite...T2006/456.hmmer/456.hmmer.test 764.00 802.00 5.0%
test-suite...ications/JM/ldecod/ldecod.test 1028.00 1079.00 5.0%
test-suite...CFP2006/444.namd/444.namd.test 1368.00 1434.00 4.8%
test-suite...marks/7zip/7zip-benchmark.test 4471.00 4685.00 4.8%
test-suite...6/464.h264ref/464.h264ref.test 3122.00 3271.00 4.8%
test-suite...pplications/oggenc/oggenc.test 1497.00 1565.00 4.5%
test-suite...T2000/300.twolf/300.twolf.test 742.00 774.00 4.3%
test-suite.../Prolangs-C/loader/loader.test 24.00 25.00 4.2%
test-suite...0.perlbench/400.perlbench.test 1983.00 2058.00 3.8%
test-suite...ications/JM/lencod/lencod.test 4612.00 4785.00 3.8%
test-suite...yApps-C++/PENNANT/PENNANT.test 995.00 1032.00 3.7%
test-suite...arks/VersaBench/dbms/dbms.test 54.00 56.00 3.7%

Diff Detail

Event Timeline

fhahn created this revision.Nov 19 2019, 9:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 19 2019, 9:00 AM
fhahn added a comment.Nov 19 2019, 9:02 AM

I am not entirely happy with the code structure, please let me know if there are any helpful utilities I am missing. Especially when it comes to dealing with sub/super registers. I might try to improve things a bit by adding iterator ranges for sub/super registers as a follow up.

fhahn marked an inline comment as done.Nov 19 2019, 9:03 AM
fhahn added inline comments.
llvm/test/CodeGen/AArch64/stp-opt-with-renaming.mir
11

it seems like we need the IR references for the test (AA?). Or is there a trick to get rid of them?

paquette added inline comments.Nov 19 2019, 10:24 AM
llvm/lib/Target/AArch64/AArch64LoadStoreOptimizer.cpp
87

Is it necessary to initialize this?

598–608

Do you specifically only want the unscaled stores here?

If not, it might make sense to use AArch64InstrInfo::isPairableLdStInst along with checking mayStore. Then we can avoid duplicating code.

808

Would it be possible to structure this loop differently so we can avoid while(true)?

(Since you're looping backwards, maybe using a reverse_iterator would work?)

815–817

Should probably check that Cur is valid at some point in this loop?

822–833

This looks very similar to the code in LiveRegUnits::stepBackward and LiveRegUnits::accumulate.

I think there's a nice opportunity to share some code there. Maybe it would make sense to add a physreg operand iterator or something and use that instead?

835

Is this comment accurate?

Maybe I'm misreading the function here, but it looks like you don't necessarily apply the function to all of the super registers. In the first loop, you can return before hitting the second loop, no?

850–851

Would it make sense to move this to LiveRegUnits?

869

Do you have to use this->TRI in these functions? Can you just pass TRI in the capture instead?

921–927

Instead of using a bool, how about

if (any_of(...))
  break;
1343

This function is pretty long, but if I'm counting braces right, it always returns false when this if is false.

I think that something like this might be a bit clearer, and would let you reduce the level of indentation:

if (!isStore(FirstMI))
  return false;

MachineFunction &MF = ...
if (!MF.getRegInfo().tracksLiveness())
  return false;

auto *RegClass...
if (!RegClass)
  return false;

...
1366

IsDef?

1396

Do you actually need the else here? I think you should always return in the if branch.

1398

You can probably reduce the level of indentation here:

if (!MOP.isReg() || !TRI->regsOverlap(...))
  continue;

if (!canRenameMOP(MOP)) {
 ...
}

RequiredClasses.insert(...)
2047

This doesn't seem to be used anywhere else?

2092–2095

Might be worth a comment?

2103–2105

remove braces?

2148

remove

llvm/test/CodeGen/AArch64/stp-opt-with-renaming.mir
2

Probably better to use update_mir_test_checks.py for this one?

3

You'll probably want -verify-machineinstrs here

Also I think you can just use -run-pass instead of -start-before and -start-after here.

11

Usually it's because the MIR references some specific bit of the IR.

For example, in this test there's something like this:

(store 4 into %ir.gxf_entry_el1)

There are likely more things than this in the test, but I think (if memory serves me well), to deal with *this* specific issue you would just have to replace this MIR line with (store 4). Then you can remove the associated IR because it is no longer referenced.

So theoretically, you can just try deleting all of the IR, see what fails, and then just add back what you need.

fhahn updated this revision to Diff 230234.Nov 20 2019, 4:50 AM
fhahn marked 20 inline comments as done.

Thanks Jessica, your comments should be addressed!

llvm/lib/Target/AArch64/AArch64LoadStoreOptimizer.cpp
87

I do not think so, but I thought it's worth keeping things explicit.

598–608

yep, mayStore is enough :)

822–833

Yep, an iterator would be the nicest solution here.

835

Yep, we exit when the result of Fn evaluates to true. This is a bit weird, but was required to be usable in both cases..... An iterator would be nicer here as well.

850–851

I am not entirely sure.

921–927

after another look, this is whole loop is not required. I've replaced it with an assert, making sure the register we use for renaming is not trashed.

2047

Nope!

llvm/test/CodeGen/AArch64/stp-opt-with-renaming.mir
2

Ah yes! I'll drop the line, I've added the checks manually with additional comments.

11

Ah yes, I've adjusted the tests to not rely on IR for aliasing.

fhahn updated this revision to Diff 230532.Nov 21 2019, 1:52 PM

Updated to use iterators proposed in dependent patches, remove some callback functions.

fhahn updated this revision to Diff 230534.Nov 21 2019, 1:55 PM

Drop unnecessary include.

fhahn marked an inline comment as done.Nov 21 2019, 1:57 PM
fhahn added inline comments.
llvm/lib/Target/AArch64/AArch64LoadStoreOptimizer.cpp
835

I've added sub_and_superregs_inclusive and phys_regs_and_masks iterators in a dependent patches.

fhahn added a comment.Dec 2 2019, 7:54 AM

ping

@paquette are the refactors in line with what you envisioned?

paquette accepted this revision.Dec 5 2019, 3:05 PM

LGTM!

llvm/lib/Target/AArch64/AArch64LoadStoreOptimizer.cpp
808

Can this fit on one line if you use auto instead of MachineBasicBlock::reverse_iterator?

This revision is now accepted and ready to land.Dec 5 2019, 3:05 PM
This revision was automatically updated to reflect the committed changes.
phosek added a subscriber: phosek.Dec 11 2019, 6:49 AM

We're seeing an assertion error in Clang when compiling compiler-rt builtins for aarch64-linux-gnu with this change:

FAILED: CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o 
/b/s/w/ir/k/recipe_cleanup/clanga0lNQB/llvm_build_dir/./bin/clang --target=aarch64-unknown-linux-gnu --sysroot=/b/s/w/ir/k/cipd/linux-arm64 -DVISIBILITY_HIDDEN  -O2 -g -DNDEBUG    -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o -MF CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o.d -o CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o   -c /b/s/w/ir/k/llvm-project/compiler-rt/lib/builtins/multc3.c
clang-10: /b/s/w/ir/k/llvm-project/llvm/include/llvm/MC/MCRegisterInfo.h:677: llvm::MCRegUnitIterator::MCRegUnitIterator(llvm::MCRegister, const llvm::MCRegisterInfo *): Assertion `Reg && "Null register has no regunits"' failed.
clang-10: error: unable to execute command: Aborted
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)
fhahn added a comment.Dec 11 2019, 8:16 AM

We're seeing an assertion error in Clang when compiling compiler-rt builtins for aarch64-linux-gnu with this change:

FAILED: CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o 
/b/s/w/ir/k/recipe_cleanup/clanga0lNQB/llvm_build_dir/./bin/clang --target=aarch64-unknown-linux-gnu --sysroot=/b/s/w/ir/k/cipd/linux-arm64 -DVISIBILITY_HIDDEN  -O2 -g -DNDEBUG    -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o -MF CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o.d -o CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o   -c /b/s/w/ir/k/llvm-project/compiler-rt/lib/builtins/multc3.c
clang-10: /b/s/w/ir/k/llvm-project/llvm/include/llvm/MC/MCRegisterInfo.h:677: llvm::MCRegUnitIterator::MCRegUnitIterator(llvm::MCRegister, const llvm::MCRegisterInfo *): Assertion `Reg && "Null register has no regunits"' failed.
clang-10: error: unable to execute command: Aborted
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)

Looks like the patch missed to skip debug operands in an assertion. I will push a fix shortly.

fhahn added a comment.Dec 11 2019, 8:28 AM

We're seeing an assertion error in Clang when compiling compiler-rt builtins for aarch64-linux-gnu with this change:

FAILED: CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o 
/b/s/w/ir/k/recipe_cleanup/clanga0lNQB/llvm_build_dir/./bin/clang --target=aarch64-unknown-linux-gnu --sysroot=/b/s/w/ir/k/cipd/linux-arm64 -DVISIBILITY_HIDDEN  -O2 -g -DNDEBUG    -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o -MF CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o.d -o CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o   -c /b/s/w/ir/k/llvm-project/compiler-rt/lib/builtins/multc3.c
clang-10: /b/s/w/ir/k/llvm-project/llvm/include/llvm/MC/MCRegisterInfo.h:677: llvm::MCRegUnitIterator::MCRegUnitIterator(llvm::MCRegister, const llvm::MCRegisterInfo *): Assertion `Reg && "Null register has no regunits"' failed.
clang-10: error: unable to execute command: Aborted
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)

Looks like the patch missed to skip debug operands in an assertion. I will push a fix shortly.

Should be fixed by rG4fe92abceb9a

We're seeing an assertion error in Clang when compiling compiler-rt builtins for aarch64-linux-gnu with this change:

FAILED: CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o 
/b/s/w/ir/k/recipe_cleanup/clanga0lNQB/llvm_build_dir/./bin/clang --target=aarch64-unknown-linux-gnu --sysroot=/b/s/w/ir/k/cipd/linux-arm64 -DVISIBILITY_HIDDEN  -O2 -g -DNDEBUG    -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o -MF CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o.d -o CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o   -c /b/s/w/ir/k/llvm-project/compiler-rt/lib/builtins/multc3.c
clang-10: /b/s/w/ir/k/llvm-project/llvm/include/llvm/MC/MCRegisterInfo.h:677: llvm::MCRegUnitIterator::MCRegUnitIterator(llvm::MCRegister, const llvm::MCRegisterInfo *): Assertion `Reg && "Null register has no regunits"' failed.
clang-10: error: unable to execute command: Aborted
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)

Looks like the patch missed to skip debug operands in an assertion. I will push a fix shortly.

Should be fixed by rG4fe92abceb9a

Still broken for me; with https://martin.st/temp/mingw_pformatw.c, built with clang -target aarch64-w64-mingw32 -c -O2 -g, I'm still getting the same error.

We're seeing an assertion error in Clang when compiling compiler-rt builtins for aarch64-linux-gnu with this change:

FAILED: CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o 
/b/s/w/ir/k/recipe_cleanup/clanga0lNQB/llvm_build_dir/./bin/clang --target=aarch64-unknown-linux-gnu --sysroot=/b/s/w/ir/k/cipd/linux-arm64 -DVISIBILITY_HIDDEN  -O2 -g -DNDEBUG    -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o -MF CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o.d -o CMakeFiles/clang_rt.builtins-aarch64.dir/multc3.c.o   -c /b/s/w/ir/k/llvm-project/compiler-rt/lib/builtins/multc3.c
clang-10: /b/s/w/ir/k/llvm-project/llvm/include/llvm/MC/MCRegisterInfo.h:677: llvm::MCRegUnitIterator::MCRegUnitIterator(llvm::MCRegister, const llvm::MCRegisterInfo *): Assertion `Reg && "Null register has no regunits"' failed.
clang-10: error: unable to execute command: Aborted
clang-10: error: clang frontend command failed due to signal (use -v to see invocation)

Looks like the patch missed to skip debug operands in an assertion. I will push a fix shortly.

Should be fixed by rG4fe92abceb9a

Still broken for me; with https://martin.st/temp/mingw_pformatw.c, built with clang -target aarch64-w64-mingw32 -c -O2 -g, I'm still getting the same error.

Yeah, there were some cases with non-debug $noreg operands. Fixed by rG2675a3c8806a

Yeah, there were some cases with non-debug $noreg operands. Fixed by rG2675a3c8806a

Thanks! Now it seems to work fine (so far) for me too.

dancgr added a subscriber: dancgr.Dec 20 2019, 10:22 AM
dancgr added inline comments.
llvm/lib/Target/AArch64/AArch64LoadStoreOptimizer.cpp
897

This creates a warning when compiling in debug mode for me.

Did you mean to use this?

assert(MOP.isImplicit() ||
                       (MOP.isRenamable() && !MOP.isEarlyClobber()) &&
                           "Need renamable operands");

It looks like this code is missing brackets wrapping the logical condition, like the ones from from line 886 assertion.

fhahn marked an inline comment as done.Dec 20 2019, 12:58 PM
fhahn added inline comments.
llvm/lib/Target/AArch64/AArch64LoadStoreOptimizer.cpp
897

thanks for the note, it looks like someone just fixed that in commit dc03b960d0236c18ed4382cea7bb3eb49329ed04

This change seems to have broken -ffixed-xX, we've noticed that our kernel started crashing with tip-of-tree Clang. After debugging, we found out that compiler would generate stores to x15 even though we compile with -ffixed-x15 which breaks the kernel because x15 is used to store per-cpu state. Would it be possible to revert or fix this issue ASAP please?

This change seems to have broken -ffixed-xX, we've noticed that our kernel started crashing with tip-of-tree Clang. After debugging, we found out that compiler would generate stores to x15 even though we compile with -ffixed-x15 which breaks the kernel because x15 is used to store per-cpu state. Would it be possible to revert or fix this issue ASAP please?

I've filed PR44358 to track this and I've also included a reproducer in that bug.

hans added a subscriber: hans.Jan 21 2020, 10:59 AM

This change seems to have broken -ffixed-xX, we've noticed that our kernel started crashing with tip-of-tree Clang. After debugging, we found out that compiler would generate stores to x15 even though we compile with -ffixed-x15 which breaks the kernel because x15 is used to store per-cpu state. Would it be possible to revert or fix this issue ASAP please?

I've filed PR44358 to track this and I've also included a reproducer in that bug.

In addition to that bug, which was fixed in d269255b95151dcd232c8856206b7e79d70eda29, we've bisected another miscompile in Chromium (on Android) to this revision. We don't have a reproducer yet, but figured we should send a heads up in case anyone else was seeing problems too.

The Chromium bug is here: https://bugs.chromium.org/p/chromium/issues/detail?id=1037912

fhahn added a comment.Jan 21 2020, 2:10 PM

This change seems to have broken -ffixed-xX, we've noticed that our kernel started crashing with tip-of-tree Clang. After debugging, we found out that compiler would generate stores to x15 even though we compile with -ffixed-x15 which breaks the kernel because x15 is used to store per-cpu state. Would it be possible to revert or fix this issue ASAP please?

I've filed PR44358 to track this and I've also included a reproducer in that bug.

In addition to that bug, which was fixed in d269255b95151dcd232c8856206b7e79d70eda29, we've bisected another miscompile in Chromium (on Android) to this revision. We don't have a reproducer yet, but figured we should send a heads up in case anyone else was seeing problems too.

The Chromium bug is here: https://bugs.chromium.org/p/chromium/issues/detail?id=1037912

Thanks for sharing that (and sorry for any inconvenience caused). I'm looking forward to the reproducer. Please let me know if there's anything I can do to help.

hans added a comment.Jan 21 2020, 4:31 PM

Thanks for sharing that (and sorry for any inconvenience caused). I'm looking forward to the reproducer. Please let me know if there's anything I can do to help.

We now have a diff of the code before and after this patch. I'm not that familiar with aarch64. Could you take a look and see if this makes sense: https://bugs.chromium.org/p/chromium/issues/detail?id=1037912#c70 (the full Machine IR dumps are attached to the comment before)

fhahn added a comment.Jan 21 2020, 6:59 PM

Thanks for sharing that (and sorry for any inconvenience caused). I'm looking forward to the reproducer. Please let me know if there's anything I can do to help.

We now have a diff of the code before and after this patch. I'm not that familiar with aarch64. Could you take a look and see if this makes sense: https://bugs.chromium.org/p/chromium/issues/detail?id=1037912#c70 (the full Machine IR dumps are attached to the comment before)

That's great thanks! I think I know what's going on (I'll post here as I don't have a sign-in for bugs.chromium.org).

In the problematic case it looks like we turn

renamable $w8 = KILL killed renamable $w8, implicit-def $x8
STURXi killed renamable $x8, $fp, -40 :: (store 8 into %stack.5)
$w8 = ORRWrs $wzr, killed $w25, 0, implicit-def $x8
STURXi killed renamable $x8, $fp, -32 :: (store 8 into %stack.4)

into

$w9 = KILL killed renamable $w8, implicit-def $x9
$w8 = ORRWrs $wzr, killed $w25, 0, implicit-def $x8
STPXi killed $x9, killed renamable $x8, $fp, -5 :: (store 8 into %stack.5), (store 8 into %stack.4)

On the MIR level, that seems fine, but the problem is that KILL is a noop, so it won't get lowered to any instructions, so $w9 will not contain the correct value. (The changed -5 offset should be fine, as the 64 bit variant of STP uses multiples of 8)

IIUC there are multiple ways to fix this:

  1. Change the operand flags on KILL. It seems like even though $w8 is marked as renamable we cannot freely rename the result operand. Unless I am missing something, all operands should probably tied.
  2. Add an additional copy to ensure we actually do the renaming.

If marking the operands of KILL as tied makes sense, I think that's what we should go for, as it is more general.

hans added a comment.Jan 22 2020, 8:55 AM

IIUC there are multiple ways to fix this:

  1. Change the operand flags on KILL. It seems like even though $w8 is marked as renamable we cannot freely rename the result operand. Unless I am missing something, all operands should probably tied.
  2. Add an additional copy to ensure we actually do the renaming.

If marking the operands of KILL as tied makes sense, I think that's what we should go for, as it is more general.

Do you think this fix can happen quickly? Otherwise we'd like to revert this to unbreak the compiler as soon as possible.

fhahn added a comment.Jan 22 2020, 9:28 AM

IIUC there are multiple ways to fix this:

  1. Change the operand flags on KILL. It seems like even though $w8 is marked as renamable we cannot freely rename the result operand. Unless I am missing something, all operands should probably tied.
  2. Add an additional copy to ensure we actually do the renaming.

If marking the operands of KILL as tied makes sense, I think that's what we should go for, as it is more general.

Do you think this fix can happen quickly? Otherwise we'd like to revert this to unbreak the compiler as soon as possible.

I think both approaches mentioned above will require additional discussion/feedback. I've updated canRenameUpToDef to bail out on any defs that are pseudo instructions for now in 300997c41a00b705ca10264c15910dd8d691ab75 . That should fix the issue.

fhahn added a comment.Jan 22 2020, 9:30 AM

@hans it would be great if you could confirm this fixes the issues you are seeing. If that's the case, I'll create an issue to back-port this to the 10.0 release branch.

hans added a comment.Jan 22 2020, 10:01 AM

@hans it would be great if you could confirm this fixes the issues you are seeing. If that's the case, I'll create an issue to back-port this to the 10.0 release branch.

Verified, thanks! I'll go ahead and cherry-pick it.

hans added a comment.Jan 22 2020, 11:07 AM

@hans it would be great if you could confirm this fixes the issues you are seeing. If that's the case, I'll create an issue to back-port this to the 10.0 release branch.

Verified, thanks! I'll go ahead and cherry-pick it.

Pushed to the 10.x branch in 050e1a3c2688f2daf03456cf94dd3ed79e8ebe7f