Only checks if there are no sub registers involved for now.
There are lots of failures currently which need to be fixed by various backends.
Splitting this off from https://reviews.llvm.org/D37640
Differential D37775
Add a verifier test to check the access on both sides of COPY are the same aditya_nandakumar on Sep 12 2017, 3:32 PM. Authored by
Details Only checks if there are no sub registers involved for now. Splitting this off from https://reviews.llvm.org/D37640
Diff Detail Event Timeline
Comment Actions Updated to refactor getRegSizeInBits into TargetRegisterInfo. There are 57 failures in total. Comment Actions LGTM with one suggestion
Comment Actions Also, there are various tests that need to be updated by the various backends, and I can only land once those are updated. I haven't had time to update all the backends.
Comment Actions Hi, here's the patch for the ARM GlobalISel tests: https://reviews.llvm.org/differential/diff/119563/ Comment Actions Thanks Diana. Comment Actions Hi All, I will try to cover for Igor in helping with the X86 part of this patch. AFAIU, the challenge is in getting the call/return lowering working for the case where a function's argument/return-value is a f32 or a f64. Some subtargets will use the FP stack registers (which are 80-bit wide), and other will use XMM's (which are 128-bit wide). define float @foo(float %arg1, float %arg2) { ret float %arg2 } Existing state on ToT: llc -mtriple=x86_64-linux-gnu -mattr=+sse2 -global-isel -stop-after=irtranslator body: | bb.1 (%ir-block.0): liveins: %xmm0, %xmm1 %0:_(s32) = COPY %xmm0 %1:_(s32) = COPY %xmm1 %xmm0 = COPY %1(s32) RET 0, implicit %xmm0 Here are some options for resolving this issue:
I haven't tried implementing any of the above options, and given my limited knowledge in GlobalISel, would appreciate any feedback on this. Thanks, Zvi Comment Actions I would definitely prefer the sizes to be right coming out of the CallLowering - so option #1.
Comment Actions This comment has been deleted.
Comment Actions X86 currently had/has three kinds of fails after this patch:
Comment Actions Updated based on Quentin's/Roman's feedback. Comment Actions I can push the getSizeInbits change in a NFC change all by itself, and then the verifier change can land separately once X86 finishes it?
|
Here we rely on having operands in MI, while previously in MachineVerifier::visitMachineInstrBefore we could discover that there are not enough operands given. Should we guard that with foundErrors?
test/CodeGen/MIR/X86/machine-verifier.mir
fails due to that reason