Yes, I haven't looked at the code itself, but that explanation seems very
plausible. The way the ISA parser works is basically if something is on the
left hand side of an =, then it's assumed to be a destination, and
otherwise it's a source. It bases its decision *purely* on text, with no
understand of liveness, where values came from, or even more subtle things
like being set by a function when passed by reference.
One trick you can use, and which you'll find in other places in the ISA
descriptions (particularly ARM I think), is to assign the result of a
computation to a temporary like "result" which doesn't mean anything to the
parser. Then you can use that variable to compute flags, etc, without the
parser thinking you're reading the original version of that register.
Separately, you can assign result to the destination register, which the
also successfully tell the parser how to treat that operand.
uint64_t result = Src1 * Src2;
computeFlags(result);
Dest = result;
I have some grand plans for how to make the parser and ISA generation in
general more sophisticated in several different ways, at which point these
sorts of tricks will hopefully be unnecessary. In the meantime though, this
may help solve your problem. If it works, please send out a review so we
can fix this for other folks too.
Gabe
On Fri, Jul 23, 2021 at 12:20 PM Mohit Gambhir via gem5-users <
gem5-users@gem5.org> wrote:
> Hi Gabe,
>
> I think your code has not yet made into stable/master branch. I see that
> in develop branch INTREG_IMPLICIT is no longer there and is replaced by
> INTREG_PRODHI and INTREG_PRODLO
>
> However, I see that even in develop branch there are two classes that are
> generated - Mul1s and Mul1sFlags. In Mul1s INTREG_PRODLO and INTREG_PRODHI
> are not added as source and are only added as destination. But in
> Mul1sFlags class they are added both as source and destination.
>
> class Mul1s : public X86ISA::RegOpT<X86ISA::FoldedSrc1Op,
> X86ISA::FoldedSrc2Op>
> {
> ...
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src1));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src2));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> _numIntDestRegs++;
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
> _numIntDestRegs++;
> ...
> }
>
> class Mul1sFlags : public X86ISA::RegOpT<X86ISA::FoldedSrc1Op,
> X86ISA::FoldedSrc2Op>
> {
> .....
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src1));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass, src2));
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODLOW));
> _numIntDestRegs++;
> setSrcRegIdx(_numSrcRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
> setDestRegIdx(_numDestRegs++, RegId(IntRegClass,
> X86ISA::INTREG_PRODHI));
>
> }
>
> Any idea why that would be? Does it have anything to do with how Mul1s is
> defined in src/arch/x86/isa/microops/regop.isa. I see that flags_code in
> that definition does read ProdHi and ProdLow but it is being produced by
> the same instruction. Does isa_parser naively treat it as source because it
> is RHS in flags code? My understanding of isa_parser is very primitive so
> any help there will be appreciated.
>
> Thanks!
> _______________________________________________
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
