llvm dev - Mar 2020 - Manipulating Arch specific code generator state

Hello all on the list,
I’m developing a backend for the 65816, however, I need a way to store some
state, as processor flags can affect how instructions operate (including
the length of some), as well as the calling convention. I need to track for
each of these flags (x, m, and e) Set, Unset, Indeterminate. I was
wondering if there was a nice way to store this with the MBB, so I can make
sure everything does the right thing, and emit code to ensure the correct
mode when necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200309/736a0e49/attachment.html>

I am unfamiliar with that architecture and ISA, but quite a few architectures
have a status register and flag setting/reading instructions. You can probably
get inspiration from the X86, ARM or MIPS backends. Again, not entirely sure how
your situation is different, but I guess you don't want to store that in
machineblocks because it is something that instructions produce/consume.
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of connor
horman via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 09 March 2020 12:31
To: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] Manipulating Arch specific code generator state

Hello all on the list,
I’m developing a backend for the 65816, however, I need a way to store some
state, as processor flags can affect how instructions operate (including the
length of some), as well as the calling convention. I need to track for each of
these flags (x, m, and e) Set, Unset, Indeterminate. I was wondering if there
was a nice way to store this with the MBB, so I can make sure everything does
the right thing, and emit code to ensure the correct mode when necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200309/fe0861b3/attachment.html>

On Thu, Mar 12, 2020 at 03:49 Walter Zambotti <zambotti at iinet.net.au>
wrote:
> I am curious as to how keeping track of condition code values at compile
> time can be achieved when condition codes are only effected at execution
> time when real data is being processed. What possible changes can be made
> to the emitted code or printed asm when the actual condition code values
> aren’t known!!!
>
Its not a condition code (though its stored in the same register). There
are three processor status flags, x and m. m is the machine data size and
affects the size of the A register, values (including immediate values)
loaded by the LDA instructions/stored by STA instructions, as well as the
size of the value stored by the STZ instruction (simply stores zero), all
between 1-byte when the flag is set, and 2-bytes when the flag is clear.
The x flag is similar but affect the Y and X registers, and all load/store
sizes (including immediate sizes for loads). There is also an emulation
flag which switches into 6502 emulation mode (implying both flags), but
would rarely be unknown or known to be set. There are two instruction that
alters these flags (x and m), both with statically known values, and one
(XCE) that can both check and alter the emulation flag to a statically
known value after first explicitly setting or clearing the Carry Flag. The
flags are never altered by any instruction except explicitly via SEP/REP
or, in the case of the emulation flag, XCE).

The 65816 is generally a weird architecture doing weird stuff for backwards
compatibility with the 6502.
>
>
> I have seen this requirement come up before in other backend designs.
>
>
>
> Secondly can you please let me know if this REPLY has gone to you directly
> or via the list.   This list seems to operate a little differently to ones
> that I am use to and there doesn’t seem to be a reply option to go to the
> list.
>
It seems to have gone directly to myself and one other. I’ve manually
corrected that
>
>
> Regards
>
>
>
> Walter ZAMBOTTI
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of
*Sjoerd
> Meijer via llvm-dev
> *Sent:* Tuesday, 10 March 2020 5:19 AM
> *To:* llvm-dev at lists.llvm.org; connor horman <chorman64 at
gmail.com>
> *Subject:* Re: [llvm-dev] Manipulating Arch specific code generator state
>
>
>
> I am unfamiliar with that architecture and ISA, but quite a few
> architectures have a status register and flag setting/reading instructions.
> You can probably get inspiration from the X86, ARM or MIPS backends. Again,
> not entirely sure how your situation is different, but I guess you
don't
> want to store that in machineblocks because it is something that
> instructions produce/consume.
> ------------------------------
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
connor
> horman via llvm-dev <llvm-dev at lists.llvm.org>
> *Sent:* 09 March 2020 12:31
> *To:* llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
> *Subject:* [llvm-dev] Manipulating Arch specific code generator state
>
>
>
> Hello all on the list,
>
> I’m developing a backend for the 65816, however, I need a way to store
> some state, as processor flags can affect how instructions operate
> (including the length of some), as well as the calling convention. I need
> to track for each of these flags (x, m, and e) Set, Unset, Indeterminate. I
> was wondering if there was a nice way to store this with the MBB, so I can
> make sure everything does the right thing, and emit code to ensure the
> correct mode when necessary.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200312/9ed6ffae/attachment.html>