Re: [Tinycc-devel] Ported tcc to Solaris/Illumos x86
Hi grischka -- On 7/14/2023 6:03 AM, grischka wrote: > On 11.07.2023 07:22, Brian Callahan wrote: >> Hi all -- >> >> Attached for review/testing is a diff that enables TCC to work on >> Solaris/Illumos x86. Tested on an OpenIndiana (Illumos distro) machine, >> where all tests pass when running TCC as an i386 compiler. >> Solaris/Illumos is a multiarch environment. Modern Illumos is a 64-bit >> kernel only, but 32-bit binaries work just fine; the Illumos people care >> a lot about backwards compatibility. > > Hi, > > that sounds good. For the people who might want to try this but do > not necessarily have the same insight as you do have by now, I'd suggest > to at least try to tackle the remaining issues in the sense of an out > of the box experience: > > * configure: maybe it is possible to let configure detect this > "not smart enough" shell and if so print some informative message > (such as "Better use bash configure on this system") or maybe even > re-execute itself using bash then. > > * path to diff etc. tools: it might be possible to set the "Path" > variable in the (top section of the top level-) Makefile, conditionally > Good to know about these two. > * gcc build cross tcc on i386: Maybe it's still possible one way or > the other to detect that we're compiling for i386 even under gcc. > The logic in tcc.h is > > # if defined __i386__ && defined TCC_TARGET_I386 > # define TCC_IS_NATIVE > > For example MSVC defines just _x86_, which is why there is > > # ifdef _X86_ > # define __i386__ 1 > # endif > Will check on this. > * __start_crt_compiler: referenced symbol not found > Seems you'd need to provide this function, for example in libtcc1.a. > Google has some info about it. > This symbol is provided in the Solaris C runtime startup files, and it is linked into the binary. Which is why I think the relocation error is the real problem, and this is one is a red herring. > * relocation R_AMD64_COPY offset invalid: _DYNAMIC: offset=0xa00a08 lies > outside memory image; > > Don't know. COPY relocs normally are generated only by the tcc linker > itself for bss symbols. Is "_DYNAMIC" the symbol name? Does it have > a "symbol size" (esym->st_size) ? Try objdump -R, See also > tccelf.c:1941 > Started on this but nothing conclusive yet. ~Brian ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Ported tcc to Solaris/Illumos x86
Hi all --
Attached for review/testing is a diff that enables TCC to work on
Solaris/Illumos x86. Tested on an OpenIndiana (Illumos distro) machine,
where all tests pass when running TCC as an i386 compiler.
Solaris/Illumos is a multiarch environment. Modern Illumos is a 64-bit
kernel only, but 32-bit binaries work just fine; the Illumos people care
a lot about backwards compatibility.
Illumos is interesting because it is a variant of early Solaris 11, with
about a decade of divergence from Oracle. The way I set up support is to
declare Illumos effectively a sub TARGETOS of Solaris.
To build and test, you will want to ensure that the GNU tools are found
first in your PATH. This is because TCC assumes GNU install and GNU
diff, but on Illumos Sun install and Sun diff are found first with the
default PATH. You can fix this by running `export
PATH=/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin` before building TCC. You'll
also need to run the configure script with `bash configure` as /bin/sh
on Illumos is not smart enough to run the configure script.
As mentioned, all tests pass on Illumos i386. In order to run the tests,
you need to rebuild TCC with itself. This is because GCC on Illumos
unconditionally declares itself to be amd64, even when in i386 mode. As
such, TCC built with GCC fails the tests because TCC thinks it's a cross
compiler and the -run test errors out because of this. Once you rebuild
TCC with itself, it'll correctly think it's a native compiler and run
all the tests.
I believe all the bits for amd64 support are there and good to go.
However, there is a linker issue that prevents binaries from working
correctly. The message you receive is:
ld.so.1: : fatal: relocation error: file : symbol
__start_crt_compiler: referenced symbol not found
However, you get what I think is the real problem if you run `ldd -d` on
the binary:
relocation R_AMD64_COPY offset invalid: _DYNAMIC: offset=0xa00a08 lies
outside memory image; relocation discarded
If you can help fix this, that would be great. With that said, the i386
version of TCC ought to be enough for the vast majority of use cases for
TCC on Solaris/Illumos, so I am sharing the diff now.
Is it worth waiting around for testing or should I just go ahead and
push this to mob?
Thanks.
~Briandiff --git a/Makefile b/Makefile
index b52194a..df0ea27 100644
--- a/Makefile
+++ b/Makefile
@@ -91,6 +91,8 @@ NATIVE_DEFINES_$(CONFIG_arm64) += -DTCC_TARGET_ARM64
NATIVE_DEFINES_$(CONFIG_riscv64) += -DTCC_TARGET_RISCV64
NATIVE_DEFINES_$(CONFIG_BSD) += -DTARGETOS_$(TARGETOS)
NATIVE_DEFINES_$(CONFIG_Android) += -DTARGETOS_ANDROID
+NATIVE_DEFINES_$(CONFIG_SunOS) += -DTARGETOS_SunOS
+NATIVE_DEFINES_$(CONFIG_Illumos) += -DTARGETOS_SunOS -DTARGETOS_Illumos
NATIVE_DEFINES_$(CONFIG_pie) += -DCONFIG_TCC_PIE
NATIVE_DEFINES_$(CONFIG_pic) += -DCONFIG_TCC_PIC
NATIVE_DEFINES_no_$(CONFIG_new_macho) += -DCONFIG_NEW_MACHO=0
diff --git a/configure b/configure
index 6ec98f3..63227ff 100755
--- a/configure
+++ b/configure
@@ -61,6 +61,9 @@ targetos=`uname`
if test "$targetos" = "Linux" ; then
test "$(uname -o)" = "Android" && targetos=Android
fi
+if test "$targetos" = "SunOS" ; then
+ test "$(uname -o)" = "illumos" && targetos=Illumos
+fi
case $targetos in
Darwin)
@@ -99,6 +102,12 @@ case $targetos in
tcc_switches="-Wl,-rpath=$sysroot/lib,-section-alignment=0x1000"
fi
;;
+ SunOS)
+confvars="$confvars SunOS"
+;;
+ Illumos)
+confvars="$confvars Illumos"
+;;
*)
;;
esac
@@ -388,6 +397,9 @@ if test -z "$cross_prefix" ; then
if test -f "/usr/lib64/crti.o" ; then
tcc_lddir="lib64"
fi
+ if test -f "/usr/lib/amd64/crti.o" ; then
+tcc_lddir="lib/amd64"
+ fi
fi
fi
diff --git a/conftest.c b/conftest.c
index ad7275c..7d883ba 100644
--- a/conftest.c
+++ b/conftest.c
@@ -20,6 +20,8 @@ const char *platform_macros[] = {
"__FreeBSD_kernel__", "TARGETOS_FreeBSD_kernel",
"__OpenBSD__", "TARGETOS_OpenBSD",
"__NetBSD__", "TARGETOS_NetBSD",
+"__illumos__", "TARGETOS_Illumos",
+"__sun__", "TARGETOS_SunOS",
"__linux__","TARGETOS_Linux",
"__ANDROID__", "TARGETOS_ANDROID",
@@ -200,6 +202,10 @@ int main(int argc, char **argv)
# define TRIPLET_OS "netbsd"
#elif defined(__OpenBSD__)
# define TRIPLET_OS "openbsd"
+#elif defined(__illumos__)
+# define TRIPLET_OS "illumos"
+#elif defined(__sun__)
+# define TRIPLET_OS "solaris"
#elif defined(_WIN32)
# define TRIPLET_OS "win32"
#elif defined(__APPLE__)
diff --git a/include/tccdefs.h b/include/tccdefs.h
index f6c25a4..a606288 100644
--- a/include/tccdefs.h
+++ b/include/tccdefs.h
@@ -60,6 +60,14 @@
#if defined _WIN32
#define __WCHAR_TYPE__ unsigned short
#define __WINT_TYPE__ unsigned short
+#elif defined __sun__
+#ifdef __ILP32__
+#define __WCHAR_TYPE__ long
+#define __WINT_TYPE__ long
+#else
Re: [Tinycc-devel] a.out support (was Re: add an executable format?)
Hello -- On 2/4/2023 8:31 AM, tccm wrote: > On Sat, Jan 21, 2023 at 07:03:52AM +0100, tccm wrote: >> I will test your patch and report here. > > Hello Brian, > > Many thanks for your code, it helped a lot. > Glad to hear that it helped. One thing I noticed in your elf2aout.c comments is that Minix-2 only supports 14-character file names. You can make the temp file much shorter if needed (e.g., hard code it to be something like "temp.aout"). Would it be possible for you to share binaries of your new TCC? I finally got Minix-2 i386 running on VirtualBox and it would be nice to try out TCC there. ~Brian ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] add an executable format?
Hello --
On 1/17/2023 2:23 AM, tccm wrote:
> On Mon, Jan 16, 2023 at 05:21:26PM +0100, tccm wrote:
>> Would some developer familiar with the tinycc internals be kind to help
>> with adding the needed minimal aout support, by giving directions
>> for the modification or, best of all, by adding the support?
>>
>> There is no need to handle aout object files, only statically linked
>> executables.
>
> Answering an off-list question:
>
Guessing I'm the off-list question.
I found an elf2aout converter for Minix buried in the Minix3 source tree.
Here is a patch to generate a.out executables. As I don't have a Minix2
machine, I can't verify it works. But it should get you there, or very
close to there. If there's some VirtualBox image of Minix2 that I can
download, I can test myself. As this will only work with i386 Minix2, I
don't think it's worthy of incorporation into the tcc tree. Having it
on-list will preserve the history, which is probably good enough for any
potential future maintenance of this patch.
You will need to apply the patch and then run the configure script with
the new --aout flag.
HTH.
~Brian
diff --git a/Makefile b/Makefile
index bfd70d2..75c93fa 100644
--- a/Makefile
+++ b/Makefile
@@ -203,7 +203,7 @@ INC-$(TR) ?= {B}/include:/usr/$(TRIPLET-$T)/include
endif
CORE_FILES = tcc.c tcctools.c libtcc.c tccpp.c tccgen.c tccdbg.c tccelf.c
tccasm.c tccrun.c
-CORE_FILES += tcc.h config.h libtcc.h tcctok.h
+CORE_FILES += tcc.h config.h libtcc.h tcctok.h elf2aout.c
i386_FILES = $(CORE_FILES) i386-gen.c i386-link.c i386-asm.c i386-asm.h
i386-tok.h
i386-win32_FILES = $(i386_FILES) tccpe.c
x86_64_FILES = $(CORE_FILES) x86_64-gen.c x86_64-link.c i386-asm.c x86_64-asm.h
diff --git a/configure b/configure
index 6fe8248..f02e047 100755
--- a/configure
+++ b/configure
@@ -50,6 +50,7 @@ ar_set=
darwin=
cpuver=
dwarf=
+aout="no"
# use CC from environment when set
test -n "$CC" && cc="$CC"
@@ -159,6 +160,8 @@ for opt do
;;
--dwarf=*) dwarf=`echo $opt | cut -d '=' -f 2-`
;;
+ --aout) aout="yes"
+ ;;
--enable-cross) confvars="$confvars cross"
;;
--disable-static) confvars="$confvars static=no"
@@ -354,6 +357,7 @@ Advanced options (experts only):
--config-new_macho=noUse apple old macho object format
--config-codesignUse codesign on apple to sign executables
--dwarf=xUse dwarf debug info instead of stabs (x=2..5)
+ --aout Generate a.out instead of ELF executables
EOF
exit 1
fi
@@ -555,6 +559,12 @@ cat >>$TMPH <>$TMPH &1
if test $? -ne 0 ; then
mv -f $TMPH config.h
diff --git a/elf2aout.c b/elf2aout.c
new file mode 100644
index 000..28f4583
--- /dev/null
+++ b/elf2aout.c
@@ -0,0 +1,522 @@
+/* $NetBSD: elf2aout.c,v 1.11 2004/04/23 02:55:11 simonb Exp $ */
+
+/*
+ * Copyright (c) 1995
+ * Ted Lemon (hereinafter referred to as the author)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/* elf2aout.c
+
+ This program converts an elf executable to a NetBSD a.out executable.
+ The minimal symbol table is copied, but the debugging symbols and
+ other informational sections are not. */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "elf.h"
+#include "tcc.h"
+
+#ifdef TCC_GENERATE_AOUT
+
+struct sect {
+ unsigned long vaddr;
+ unsigned long len;
+};
+
+ST_FUNC intcombine(struct sect *, struct sect *, int);
+ST_FUNC intphcmp(const void *, const void *);
+ST_FUNC char *saveRead(int file, off_t offset, off_t len, char *name);
+ST_FUNC
[Tinycc-devel] tcc broken on OpenBSD when using --config-pie (diff included)
Hi tcc list --
I was looking to update the OpenBSD package of tcc. I saw that recently,
a configure option for PIE binaries was added. This would be very
desirable for us, so I tried to enable it only to find that all binaries
produced with --config-pie were broken. This is because tcc incorrectly
tries to use crtbeginS.o and crtendS.o when linking PIE binaries on
OpenBSD. Those files should only be used when creating shared libraries.
This diff fixes things. With it, tcc links the correct files both for
PIE binaries and shared libraries. This was tested against the in-base
clang compiler that ships with OpenBSD.
I plan to push this to mob unless there are concerns. I don't know if
something similar needs to be done for FreeBSD or NetBSD.
~Brian
diff --git a/libtcc.c b/libtcc.c
index 4327a13..3102961 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -924,7 +924,7 @@ LIBTCCAPI int tcc_set_output_type(TCCState *s, int
output_type)
#if TARGETOS_OpenBSD
if (output_type != TCC_OUTPUT_DLL)
tcc_add_crt(s, "crt0.o");
-if (output_type & TCC_OUTPUT_DYN)
+if (output_type == TCC_OUTPUT_DLL)
tcc_add_crt(s, "crtbeginS.o");
else
tcc_add_crt(s, "crtbegin.o");
diff --git a/tccelf.c b/tccelf.c
index 1103f3d..c340b3e 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -1518,11 +1518,16 @@ ST_FUNC void tcc_add_runtime(TCCState *s1)
if (s1->output_type != TCC_OUTPUT_MEMORY) {
#if defined TCC_TARGET_MACHO
/* nothing to do */
-#elif TARGETOS_OpenBSD || TARGETOS_FreeBSD || TARGETOS_NetBSD
+#elif TARGETOS_FreeBSD || TARGETOS_NetBSD
if (s1->output_type & TCC_OUTPUT_DYN)
tcc_add_crt(s1, "crtendS.o");
else
tcc_add_crt(s1, "crtend.o");
+#elif TARGETOS_OpenBSD
+ if (s1->output_type == TCC_OUTPUT_DLL)
+ tcc_add_crt(s1, "crtendS.o");
+ else
+ tcc_add_crt(s1, "crtend.o");
# if !TARGETOS_OpenBSD
tcc_add_crt(s1, "crtn.o");
# endif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] 回复： bug
On 6/8/2022 11:12 AM, lrt wrote:
> int main(int argc, char **argv)
> {
> printf("Hello!\n");
> //uint64_t n = 0x;
> //printf("%lld\n", n);
> printf("%lld\n", 0x);
> printf("%llu\n", 0x);
> return 0;
> }
> output:
> Hello!
> 247414872441159679
> 247414872441159679
>
> Remove comments，different result.
You were already told once by Kyryl to update your TCC version or let us
know what platform and TCC version you're using. You still haven't done
either. It is impossible to help you without more information, though
Kyryl's suggestion of update your version of TCC is almost certainly the
correct one. (Alternatively, did you write your own libc and get printf
format string handling totally wrong?)
It would be near unbelievable if TCC couldn't correctly handle such a
simple program. But of course, it does.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bug
On 6/8/2022 10:51 AM, Brian Callahan wrote:
> On 6/8/2022 10:03 AM, lrt via Tinycc-devel wrote:
>> Find a bug!
>>
>> #include
>> #include
>> #include
>>
>> int main(int argc, char **argv)
>> {
>> printf("Hello!\n");
>> printf("%lld\n", 641*6700417);
>> return 0;
>> }
>> output:
>> Hello!
>> 7035757726269441
>>
>> Right is :
>> Hello!
>> 4294967297
>>
>
> No, 4294967297 is not the correct output for this program. Check it
> yourself. You'll get this warning with both GCC and Clang:
>
> /home/brian/c $ gcc --version
> gcc (GCC) 13.0.0 20220508 (experimental)
> Copyright (C) 2022 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> /home/brian/c $ gcc -O2 -o bug bug.c
> bug.c: In function 'main':
> bug.c:8:29: warning: integer overflow in expression of type 'int'
> results in '1' [-Woverflow]
> 8 | printf("%lld\n", 641*6700417);
> | ^
> /home/brian/c $ ./bug
> Hello!
> 1
> /home/brian/c $ tcc --version
> tcc version 0.9.27 mob:afc1362 (x86_64 OpenBSD)
> /home/brian/c $ tcc -o bug bug.c
> /home/brian/c $ ./bug
> Hello!
> 1
>
> If you really want 4294967297 to be output, change 6700417 to 6700417L
Typed too fast, should be LL here.
.
> Works with both GCC and TCC.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bug
On 6/8/2022 10:03 AM, lrt via Tinycc-devel wrote:
> Find a bug!
>
> #include
> #include
> #include
>
> int main(int argc, char **argv)
> {
> printf("Hello!\n");
> printf("%lld\n", 641*6700417);
> return 0;
> }
> output:
> Hello!
> 7035757726269441
>
> Right is :
> Hello!
> 4294967297
>
No, 4294967297 is not the correct output for this program. Check it
yourself. You'll get this warning with both GCC and Clang:
/home/brian/c $ gcc --version
gcc (GCC) 13.0.0 20220508 (experimental)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/home/brian/c $ gcc -O2 -o bug bug.c
bug.c: In function 'main':
bug.c:8:29: warning: integer overflow in expression of type 'int'
results in '1' [-Woverflow]
8 | printf("%lld\n", 641*6700417);
| ^
/home/brian/c $ ./bug
Hello!
1
/home/brian/c $ tcc --version
tcc version 0.9.27 mob:afc1362 (x86_64 OpenBSD)
/home/brian/c $ tcc -o bug bug.c
/home/brian/c $ ./bug
Hello!
1
If you really want 4294967297 to be output, change 6700417 to 6700417L.
Works with both GCC and TCC.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] dwarf support
An FYI for packagers: dwarf.h is dual-licensed LGPLv3+ or GPLv2+. This is different than the rest of tcc which is LGPLv2+. ~Brian On 5/5/2022 5:13 AM, Herman ten Brugge via Tinycc-devel wrote: > The new gcc12 release does not support stabs any more. > This was a good reason to add support for dwarf. > > You can enable this by configuring with option --dwarf=x where x=2..5 > Most targets should support version 5. > > Apple probably needs some adjustments in tccmacho.c for this to work. > I do not know how well supported dwarf is on apple. > > I tested this on x86_64, i386, arm, arm64 and riscv64 on > fedora/raspberry pi/*bsd. > All testcases work and most targets support dwarf-5. > > Herman > > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.
Seeing as I've had all positive feedback on this, here's a more complete
diff that I think is suitable for committing.
It does the following:
1. Converts movl $0, %e{ax,cx,dx,sp,si,di} to xorl
%e{ax,cx,dx,sp,si,di}, %e{ax,cx,dx,sp,si,di}
2. Converts movq $0, %r{ax,cx,dx,sp,si,di} to xorl
%e{ax,cx,dx,sp,si,di}, %e{ax,cx,dx,sp,si,di}
There are two places where these idioms can be emitted, so it handles
both cases.
Here are some before and after .text size numbers:
bin old new diff%reduction
--- --- --- --
tcc 328786 321358 74282.26
libtcc.a307288 300252 70362.29
bcheck.o23254 22801 453 1.95
bt-exe.o47324550182 3.85
bt-log.o648 639 9 1.39
libtcc1.a 12678 12119 559 4.41
There is no change in compilation speed as far as I can measure.
There is an additional third location where a mov $0, %eax can be
emitted. It's in the form:
mov $0, %eax
jmp eb 05
mov $1, %eax
-or-
mov $1, %eax
jmp eb 05
mov $0, %eax
I could not find where this was happening, and the one place that looks
like it would be the place seems not to be. I don't think it impedes the
review and committing of this diff. And it'll give me something to do on
a rainy day if no one else beats me to it :)
At this point, I'd like any feedback on the diff below and/or
encouragement to commit it to mob.
Thanks.
~Brian
diff --git a/x86_64-gen.c b/x86_64-gen.c
index 81ec5d9..5085a0a 100644
--- a/x86_64-gen.c
+++ b/x86_64-gen.c
@@ -483,11 +483,21 @@ void load(int r, SValue *sv)
}
#endif
} else if (is64_type(ft)) {
-orex(1,r,0, 0xb8 + REG_VALUE(r)); /* mov $xx, r */
-gen_le64(sv->c.i);
+if (sv->c.i == 0 && r < 8) {
+o(0x31); /* xor r, r */
+o(0xc0 + REG_VALUE(r) * 9);
+} else {
+orex(1,r,0, 0xb8 + REG_VALUE(r)); /* mov $xx, r */
+gen_le64(sv->c.i);
+}
} else {
-orex(0,r,0, 0xb8 + REG_VALUE(r)); /* mov $xx, r */
-gen_le32(fc);
+if (fc == 0 && r < 8) {
+o(0x31); /* xor r, r */
+o(0xc0 + REG_VALUE(r) * 9);
+} else {
+orex(0,r,0, 0xb8 + REG_VALUE(r)); /* mov $xx, r */
+gen_le32(fc);
+}
}
} else if (v == VT_LOCAL) {
orex(1,0,r,0x8d); /* lea xxx(%ebp), r */
@@ -1422,8 +1432,12 @@ void gfunc_call(int nb_args)
}
}
-if (vtop->type.ref->f.func_type != FUNC_NEW) /* implies FUNC_OLD or
FUNC_ELLIPSIS */
-oad(0xb8, nb_sse_args < 8 ? nb_sse_args : 8); /* mov
nb_sse_args, %eax */
+if (vtop->type.ref->f.func_type != FUNC_NEW) { /* implies FUNC_OLD
or FUNC_ELLIPSIS */
+if (nb_sse_args == 0)
+o(0xc031); /* xor eax, eax */
+else
+oad(0xb8, nb_sse_args < 8 ? nb_sse_args : 8); /* mov
nb_sse_args, %eax */
+}
gcall_or_jmp(0);
if (args_size)
gadd_sp(args_size);
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.
On 4/5/2022 9:03 PM, Brian Callahan wrote: > bin old new diff%reduction > --- --- --- -- > tcc 328786 325878 29080.88 > libtcc.a 20214 20213 201 0.99 > bcheck.o 23254 23209 45 0.19 > bt-exe.o 4732469339 0.82 > bt-log.o 648 648 0 0 > libtcc1.a 12678 12498 180 1.42 Copied the wrong numbers for libtcc.a -- here's the real numbers: old new diff%reduction --- --- -- 307288 304487 28010.91 ~Brian ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.
So then let's take it slow, starting with the lowest of low-hanging
fruit and showing numbers along the way.
The patch below improves the x86_64 codegen to convert:
movl $0, %e{ax,cx,dx,sp,si,di}
to:
xorl %e{ax,cx,dx,sp,si,di}, %e{ax,cx,dx,sp,si,di}
Here are benchmark numbers of the .text sizes of a 3-way bootstrap tcc,
before this patch (old) and after this patch (new):
bin old new diff%reduction
--- --- --- --
tcc 328786 325878 29080.88
libtcc.a20214 20213 201 0.99
bcheck.o23254 23209 45 0.19
bt-exe.o4732469339 0.82
bt-log.o648 648 0 0
libtcc1.a 12678 12498 180 1.42
So it's not much, but it's also not nothing (except for the bt-log.o
case, where it literally is nothing).
And timing results for the compiling tcc.c 10 times test:
old new
--- ---
1010 ms 1008 ms
...which is just a fancy way of saying there appears to be no
statistical difference in speed after applying this patch. All these
measurements were run on my machine, which is an OpenBSD/amd64 machine
with a very old and slow i3 CPU.
This patch could easily be applied to movq $0, %r{ax,cx,dx,sp,si,di},
which I'll send in a follow-up email. The %r8-%15 and equivalent
%r8d-%r15d conversions are slightly different. The i386 codegen should
be able to have a mechanical translation of this diff applied to it as well.
~Brian
diff --git a/x86_64-gen.c b/x86_64-gen.c
index 81ec5d9..775e132 100644
--- a/x86_64-gen.c
+++ b/x86_64-gen.c
@@ -486,8 +486,13 @@ void load(int r, SValue *sv)
orex(1,r,0, 0xb8 + REG_VALUE(r)); /* mov $xx, r */
gen_le64(sv->c.i);
} else {
-orex(0,r,0, 0xb8 + REG_VALUE(r)); /* mov $xx, r */
-gen_le32(fc);
+if (fc == 0 && r < 8) {
+o(0x31); /* xor r, r */
+o(0xc0 + REG_VALUE(r) * 9);
+} else {
+orex(0,r,0, 0xb8 + REG_VALUE(r)); /* mov $xx, r */
+gen_le32(fc);
+}
}
} else if (v == VT_LOCAL) {
orex(1,0,r,0x8d); /* lea xxx(%ebp), r */
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.
Hello -- I am on this list, you know :) There may well be opportunities in tcc for a peephole optimizer approach, but I'll caution that each compiler is different and that blog post was examining QBE, so it wouldn't necessarily be a direct 1:1 mapping. QBE does a lot of optimization itself before writing out its final assembly. ~Brian On 4/4/2022 10:26 AM, Domingo Alvarez Duarte wrote: > After reading this https://briancallahan.net/blog/20220330.html and > using a citation on this list about dumping the ASM generated by TCC > using objdump maybe we can find patterns on the generated code and > identify where it's produced and update then. > > On 31/3/22 20:16, rempas via Tinycc-devel wrote: >> 31 Μαρ 2022, 19:35 Από david.k...@libertysurf.fr: >> >>> Have a look : https://github.com/adorad/tcc and >>> https://github.com/adorad/adorad >>> >>> - Mail d'origine - >>> De: rempas via Tinycc-devel >>> À: Tinycc Devel >>> Cc: rem...@tutanota.com, Tinycc Devel >>> Envoyé: Tue, 29 Mar 2022 21:12:37 +0200 (CEST) >>> Objet: Re: [Tinycc-devel] Re : Some questions regarding of TCC's >>> optimizations. >>> >> Thanks a lot! I will look at it! >> >> >> ___ >> Tinycc-devel mailing list >> Tinycc-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Commit 0c6adcb (tccgen: multi-dimensional vla: bug fixes) causes segfaults on OpenBSD
Hi again -- On 3/16/2022 4:51 PM, Brian Callahan wrote: > Hello TinyCC developers -- > > One of the three commits from today, 0c6adcb (tccgen: multi-dimensional > vla: bug fixes), causes tcc to segfault on OpenBSD. > Fixed as of 291eccc (Vla fix for 64 bits targets) -- thanks! ~Brian ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Commit 0c6adcb (tccgen: multi-dimensional vla: bug fixes) causes segfaults on OpenBSD
Hello TinyCC developers -- One of the three commits from today, 0c6adcb (tccgen: multi-dimensional vla: bug fixes), causes tcc to segfault on OpenBSD. Here is the test log: ``` hello-exe Hello World hello-run Hello World libtest Hello World! fib(32) = 2178309 add(32, 64) = 96 libtest_mt running fib with mixed calls 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946 (55 ms) running fib in threads 1 55 144 3 13 6765 377 21 34 5 2584 1597 10946 233 8 2 987 89 4181 610 (49 ms) running tcc.c in threads to run fib gmake[2]: *** [Makefile:95: libtest_mt] Segmentation fault (core dumped) gmake[1]: *** [Makefile:83: all] Error 2 ``` Commit ec5d942 (tccgen: accept array-size expressions in function paramters) works OK. Also, applying commit 719d966 (tccgen: Allow struct init from struct) directly on top of commit ec5d942 also works OK. It is just commit 0c6adcb that is causing issues. Please let me know if anything else is needed to help fix the issue. Thanks. ~Brian ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] OpenBSD/riscv64 support
On Saturday, July 10th, 2021 at 2:01 AM, Christian Jullien wrote: > --- > > OpenBSD | arm | gcc/clang | WIP > > | arm64 | gcc/clang/tcc | Ok (tcc not tested) > > | riscv64 | gcc | Ok > > | x64 | gcc/clang/tcc | Ok > > | x86 | gcc/clang/tcc | Ok > > +-+---+--- We ship packages on all these platforms, so it must build with clang. Additionally, the arm platform works fine, evidenced by all tests passing, with one exception being an incidental difference in rounding in one test. ~Brian___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] OpenBSD/riscv64 support
Hello tinycc list -- I just pushed support for OpenBSD/riscv64 to tinycc (OpenBSD does not support 32-bit riscv). It should be a total no-op on all other platforms. Thanks. ~Brian ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
