llvm dev - Feb 2015 - [LLVMdev] clang .code16 with -Os producing larger code that it needs to

On Fri, 2015-02-20 at 16:05 +0000, David Woodhouse
wrote:
> 
> It's been a while since I looked at this... but I think for the short
> jumps we just emit the 8-bit version and there's a fixup which can go
> back and re-emit the instruction in 32-bit mode if it finds it doesn't
> fit?
> 
> Do we just need to support a similar fixup for promoting 16-bit to
> 32-bit relocations?
OK, the term I was looking for was 'relaxation'. Look in
lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp for
X86AsmBackend::relaxInstruction() and related methods.

Observe that it will cope with 'relaxing' 8-bit PC-relative relocations
to 32-bit PC-relative, but it doesn't cope with anything else.

Your task, should you choose to accept it, is to make it cope with other
forms of relaxation where necessary.

Note that the existing cases end up emitting a new instruction with a
*new* opcode. In your case it won't be doing that. It's the *same*
opcode, but you'll have to set a flag to tell the emitter to use the
32-bit addressing mode (for data and/or addr as appropriate) this time.

And while you're doing that, you should note that that's the *same* flag
that'll be needed to support explicit addr32/data32 prefixes in the asm
source. So you might as well support those too. I might suggest doing
them *first*, in fact.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150220/d97aa989/attachment.bin>

> Your task, should you choose to accept it, is to make it cope with other
> forms of relaxation where necessary.
And if not, please open a bug :-)

There are a few other missing cases that cause MC to produce code that
is more "relaxed" than it needs to be.

Cheers,
Rafael

On Fri, 2015-02-20 at 13:47 -0500, Rafael Espíndola
wrote:
> > Your task, should you choose to accept it, is to make it cope with
other
> > forms of relaxation where necessary.
> 
> And if not, please open a bug :-)
http://llvm.org/bugs/show_bug.cgi?id=22662

FWIW I could reproduce the 'movl foo, %ebx' one but a relative jump
*was* using 16 bits (although gas uses 8):

 $ cat foo.S
.code16
	jae foo
	movl (foo), %ebx
foo:
 $ gcc -c -oa.out foo.S   ; llvm-objdump -d -triple=i686-pc-linux-code16  

a.out:	file format ELF64-x86-64

Disassembly of section .text:
.text:
       0:	73 05                                        	jae	5
       2:	66 8b 1e 00 00                               	movl	0, %ebx
 $ llvm-mc -filetype=obj foo.S | llvm-objdump -d -triple=i686-pc-linux-code16 - 

<stdin>:	file format ELF64-x86-64

Disassembly of section .text:
.text:
       0:	0f 83 08 00                                  	jae	8
       4:	67 66 8b 1d 00 00 00 00                      	movl	0, %ebx


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150223/da6fa2ea/attachment.bin>