chore(deps): bump ext/llvm-project from 8e85b77 to 851da60

[dependabot]

Bumps ext/llvm-project from 8e85b77 to 851da60.

Commits

• 851da60 Revert "[LLVM] Use reportFatalUsageError for LTO usage errors" (#141000)
• 6074d83 [mlir] Remove unused local variables (NFC) (#140990)
• 7ffa491 [lldb] Remove unused local variables (NFC) (#140989)
• bf241e8 [clang] Avoid creating temporary instances of std::string (NFC) (#140988)
• 09c3d14 [IA] Add support for [de]interleave{3,5,7} (#139373)
• 0641ca1 [BOLT] Avoid creating a temporary instance of std::string (NFC) (#140987)
• 7e4e33e [mlir] Use llvm::is_contained (NFC) (#140986)
• 7c8b397 [BOLT] Use llvm::is_contained (NFC) (#140984)
• 6d2a7b4 [clang] Use llvm::find_if (NFC) (#140983)
• 287294d [ConstraintElim] Do not allow overflows in Decomposition (#140541)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #814.

[AFOliveira]

@lenary, can you please give me a brief explanation here? It seems that .vxm instructions have v0 in the "AsmString" and in the "InOperandList", but the variable is nowhere to be seen in "Inst". Does this mean the variable exists in the assembly but not as a variable in hardware? I've tried looking it up in the spec, but I couldn't find the necessary information to understand how v0 is encoded. It's not clear to me if it is hardcoded in hardware or not, and if it is hardcoded, why would we need it to show up in assembly?

[ThinkOpenly]

It seems that .vxm instructions have v0 in the "AsmString" and in the "InOperandList", but the variable is nowhere to be seen in "Inst". Does this mean the variable exists in the assembly but not as a variable in hardware?

The Sail code might be instructive:

mapping vxmtype_mnemonic : vxmfunct6 <-> string = {
  VXM_VMADC    <-> "vmadc.vxm", /* carry in, carry out */
  VXM_VMSBC    <-> "vmsbc.vxm"
}
    
mapping clause assembly = VXMTYPE(funct6, vs2, rs1, vd)
  <-> vxmtype_mnemonic(funct6) ^ spc() ^ vreg_name(vd) ^ sep() ^ vreg_name(vs2) ^ sep() ^ reg_name(rs1) ^ sep() ^ "v0"

This shows "v0" (and only that register) being always explicitly present for the "vmadc.vxm" and "vmsbc.vxm" instructions.

However, it is not part of the encoding:

mapping clause encdec = VXMTYPE(funct6, vs2, rs1, vd)
  <-> encdec_vxmfunct6(funct6) @ 0b0 @ encdec_vreg(vs2) @ encdec_reg(rs1) @ 0b100 @ encdec_vreg(vd) @ 0b1010111

So, it must be part of the assembly and can only be "v0", but it is only implicit in the encoding. .vfm, .vim, and .vvm instructions are similar.

[AFOliveira]

Yes, I looked at it and it is exactly that. It is hardcoded in hardware, but assembly still defines it. The other problem is that LLVM considers it to be vm with the most recent changes, but I need to go through git blame and understand why that was made.

[lenary]

Sorry, I was out-of-office. I want to look at this today. I think we had, for a while, a situation where they were hardcoded and the mask operand was added using c++ code. As you see now, we have a VMaskCarryInOp:$vm operand - VMaskCarryInOp is a special kind of operand which can only be v0. I may need to go over with you how these RegisterOperands work, because we use them in a few places (also for Zfinx and friends).

[AFOliveira]

I think we had, for a while, a situation where they were hardcoded and the mask operand was added using c++ code

That's why this was working in the first place :) Probably a recent fix made this fail.

I may need to go over with you how these RegisterOperands work, because we use them in a few places (also for Zfinx and friends).

I would definitely appreciate that!