================ @@ -0,0 +1,66 @@ +//===-- RISCVInstrInfoZalasr.td - RISC-V 'Zalasr' instructions -------*- tablegen -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// +// This file describes the RISC-V instructions from the Zalasr (Load-Acquire +// and Store-Release) extension +// +//===----------------------------------------------------------------------===// + +//===----------------------------------------------------------------------===// +// Instruction class templates +//===----------------------------------------------------------------------===// + +let hasSideEffects = 0, mayLoad = 1, mayStore = 0 in +class LAQ_r<bit aq, bit rl, bits<3> funct3, string opcodestr> + : RVInstRAtomic<0b00110, aq, rl, funct3, OPC_AMO, + (outs GPR:$rd), (ins GPRMemZeroOffset:$rs1), + opcodestr, "$rd, $rs1"> { + let rs2 = 0; +} + +let hasSideEffects = 0, mayLoad = 0, mayStore = 1 in +class SRL_r<bit aq, bit rl, bits<3> funct3, string opcodestr> + : RVInstRAtomic<0b00111, aq, rl, funct3, OPC_AMO, + (outs ), (ins GPRMemZeroOffset:$rs1, GPR:$rs2), + opcodestr, "$rs2, $rs1"> { + let rd = 0; +} +multiclass LAQ_r_aq_rl<bits<3> funct3, string opcodestr> { + def _AQ : LAQ_r<1, 0, funct3, opcodestr # ".aq">; + def _AQ_RL : LAQ_r<1, 1, funct3, opcodestr # ".aqrl">; +} + +multiclass SRL_r_aq_rl<bits<3> funct3, string opcodestr> { + def _RL : SRL_r<0, 1, funct3, opcodestr # ".rl">; + def _AQ_RL : SRL_r<1, 1, funct3, opcodestr # ".aqrl">; +} + +//===----------------------------------------------------------------------===// +// Instructions +//===----------------------------------------------------------------------===// + + +let Predicates = [HasStdExtZalasr] in { +defm LB_AQ : LAQ_r_aq_rl<0b000, "lb">; ---------------- topperc wrote:
> Yes it does. I couldn't come up with a better alternative--since it would be > possible to encode this with neither bit set, which should just be a LB > without an immediate. That isn't useful, and so it wasn't included in the > extension, but there is the ability to specify it encoding-wise. > > Also, it can't be named LB for the same reason--it would conflict with plain > LB. The alternative is LB. (with a period/underscore after), but that is even > more confusing. I decided for both this and riscv-opcodes that this was the > simplest way--but it would lead to issues if there was a load-release, it > would be named LB_AQ_RL which would be confusing with LB_AQ_AQ_RL. Does the build fail if you name it LB here? https://github.com/llvm/llvm-project/pull/79911 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
