|
From: | Paul Cercueil |
Subject: | Re: [PATCH] ppc: Fix 'calli' when floating-point arguments are passed |
Date: | Thu, 08 Sep 2022 19:59:56 +0100 |
Hi Paulo,Le jeu., sept. 8 2022 at 14:52:28 -0300, Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade@gmail.com> a écrit :
Em qui., 8 de set. de 2022 às 14:18, Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade@gmail.com> escreveu: [snip]> The problem now is that r26 should be live at L2 but is not detected as> such.> This causes Lightning to use r26 as a temporary for the andi line 34> (lines 153-155 in the generated code). What code you use to access 'r10' and 'r3'? It is possible to useJIT_R(5) and JIT_R(12) as I did in the C code, but it is an ugly hack, taking advantage that it does not check bounds. The check/lightning.ccode need to be patched to accept it... Can you create a reproducer in C, starting with the above sample?Well, the most likely cause is that it did happen because of a lightning build without the last 3 commits, and is a side effect of the jumps to araw address: jmpi 0x20000d0c
I can assure you I triple-checked that. I removed the library in my toolchain, my program would complain that liblightning.so.0 is missing, then I just "make clean install" with the proper path, my program picks up the library just fine. And I'm at the latest origin/master, clean, no local changes. Also, others can reproduce my issue with my program + Lightning master.
Now what's really triggering me, is that I have a C program that produces the *exact* same Lightning output (see attachment). It is exactly the same, the *only* differences are the jmpi addresses, and my test program does not have the r26 missing in L2.
So even with the exact same code in a test example, I cannot reproduce it. Yet my regular program shows the bug with the exact same Lightning calls. I have absolutely no idea what's going on.
-Paul
test.c
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |