<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Yes, such optimizations are something for the "last 20%" of the
project, nice to have's.<br>
<br>
As of now, I have yet to get a feeling of what LLVM can do on its
own, depending on what it's from the instruction tables and where it
needs help, and how much in other processing stages.<br>
As this affects the way how the instruction info table will be
set-up, I appreciate your suggestions very much!<br>
<br>
Now that you mentioned using a the pseudo instruction for the
possible 16 bit LD command combinations:<br>
<br>
Regarding the heavily overlapped register structure and the
asymmetric instruction set of the Z80, would you recommend to try
mapping more instructions in the form of generic pseudos that expand
to multiple instructions during legalisation (leading to more custom
lowering code), or try to map as many instructions and variations
according to the allowed / limited operators as possible in a 1:1
way, leading to simpler lowering code (not sure if I am using the
right words here)?<br>
<br>
Thanks,<br>
Michael<br>
<br>
<div class="moz-cite-prefix">
<div id="rwhMsgHeader"><br>
<hr id="rwhMsgHdrDivider" style="border:0;border-top:1px solid
#B5C4DF;padding:0;margin:10px 0 5px 0;width:100%;"><span
style="margin: -1.3px 0 0 0 !important;"><font style="font:
12px Arial !important; color: #000000 !important;"
face="Arial" color="#000000"><b>From:</b> Bruce Hoult</font></span><br>
<span style="margin: -1.3px 0 0 0 !important;"><font
style="font: 12px Arial !important; color: #000000
!important;" face="Arial" color="#000000"><b>Sent:</b>
Wednesday, Jul 25, 2018 11:33 PM WEST</font></span><br>
<span style="margin: -1.3px 0 0 0 !important;"><font
style="font: 12px Arial !important; color: #000000
!important;" face="Arial" color="#000000"><b>To:</b> Michael
Stellmann</font></span><br>
<span style="margin: -1.3px 0 0 0 !important;"><font
style="font: 12px Arial !important; color: #000000
!important;" face="Arial" color="#000000"><b>Cc:</b> LLVM
Developers Mailing List</font></span><br>
<span style="margin: -1.3px 0 0 0 !important;"><font
style="font: 12px Arial !important; color: #000000
!important;" face="Arial" color="#000000"><b>Subject:</b>
[llvm-dev] Question about target instruction optimization</font></span><br>
<br>
</div>
</div>
<blockquote type="cite"
cite="mid:CAP8PnuTD1Wirzk5TCN5NuA73DE7tC-o1r_fCDeHCVorXSv-0-g@mail.gmail.com"
style="border:none !important; margin-left:0px !important;
margin-right:0px !important; margin-top:0px !important;
padding-left:0px !important; padding-right:0px !important">
<div dir="ltr">This is so far down the list of problems you'll
have (and the difference so trivial to program size and speed)
that I think you should ignore it until you have a working
compiler.
<div><br>
</div>
<div>As far as two registers getting the same value, that should
be picked up by common subexpression elimination in the
optimiser anyway.</div>
<div><br>
</div>
<div>You might want to consider having a pseudo-instruction for
LD {BC,DE,HL,IX,IY},<span
style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">{BC,DE,HL,IX,IY}
(all combinations are valid except those containing two of
HL,IX,IY). You could expand this very late in the assembler,
or during legalisation.</span></div>
<div><span
style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br>
</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jul 25, 2018 at 10:42 AM,
Michael Stellmann via llvm-dev <span dir="ltr"><<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border:none !important;
margin-left:0px !important; margin-right:0px !important;
margin-top:0px !important; padding-left:0px !important;
padding-right:0px !important">This is a question about
optimizing the code generation in a (new) Z80 backend:<br>
<br>
The CPU has a couple of 8 bit physical registers, e.g. H, L,
D and E, which are overlaid in 16 bit register pairs named
HL and DE.<br>
<br>
It has also a native instruction to load a 16 bit immediate
value into a 16 bit register pair (HL or DE), e.g.:<br>
<br>
LD HL,<imm16><br>
<br>
Now when having a sequence of loading two 16 bit register
pairs with the *same* immediate value, the simple approach
is:<br>
<br>
LD HL,<imm16><br>
LD DE,<imm16><br>
<br>
However, the second line can be shortened (in opcode bytes
and cycles) to load the overlaid 8 bit registers of HL (H
and L) into the overlaid 8 bit registers of DE (D and E), so
the desired result is:<br>
<br>
; optimized version: saves 1 byte and 2 cycles<br>
LD D,H (sets the high 8 bits of DE from the high 8
bits of HL)<br>
LD E,L (same for lower 8 bits)<br>
<br>
<br>
Another example: If reg pair DE needs to be loaded with
imm16 = 0, and another physical(!) register is known to be 0
(from a previous immediate load, directly or indirectly) -
assuming that L = 0 (H might be something else) - the
following code:<br>
<br>
LD DE,0x0000<br>
<br>
should become:<br>
<br>
LD D,L<br>
LD E,L<br>
<br>
I would expect that this needs to be done in a peephole
optimizer pass, as during the lowering process, the physical
registers are not yet assigned.<br>
<br>
Now my question:<br>
1. Is that correct (peephole instead of lowering)? Should
the lowering always emit the generic, not always optimal "LD
DE,<imm16>". Or should the lowering process always
split the 16 bit immediate load in two 8 bit immediate loads
(via two new virtual 8 bit registers), which would be
eliminated later automatically?<br>
2. And if peephole is the better choice, which of these is
recommended: the SSA-based Machine Code Optimizations, or
the Late Machine Code Optimizations? Both places in the LLVM
code generator docs say "To be written", so I don't really
know which one to choose... or even writing a custom pass?<br>
<br>
...and more importantly, how would I check if any physical
register contains a specific fixed value at a certain point
(in which case the optimization can be done) - or not.<br>
<br>
Michael<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>