On 7/17/25 2:24 AM, Stefan Schulze Frielinghaus wrote:
On Wed, Jul 09, 2025 at 03:48:43PM +0200, Stefan Schulze Frielinghaus wrote:
This is a follow-up to
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684181.html
I added the last missing pieces namely changelogs, and bootstrapped and
regtested on
aarch64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
s390x-ibm-linux-gnu
x86_64-pc-linux-gnu
Via cross compilers I verified the new tests for
arm-linux-gnueabi
i686-linux-gnueabi
powerpc-linux-gnu
riscv32-linux-gnu
riscv64-linux-gnu
Despite that I removed overloads for parse_{input,output}_constraint()
by passing a null pointer explicitly. Furthermore, in case of register
pairs, if two constraints of operands overlap, error out and report the
overlapped register. For example, on aarch64
svuint32x2_t x, y;
asm ("" : "={z5}" (x), "={z6}" (y));
previously I used the register as is of the first constraint in the
error message which is imprecise/misleading. Now, I error out reporting
multiple outputs to register z6/v6, i.e., the actual overlapped one, and
not z5/v5 as previously.
Although I found a lot of corner cases during development via
-fdemote-register-asm I removed it from this patch series. I
compiled and used the Linux kernel and glibc successfully with it for
s390x. For x86_64, the Linux kernel compiles fine, too, except of one
small manual change. For powerpc64le, I ran into an odd case compiling
glibc which I would like to understand in more detail. Since register
asm is not as strict as hard register constraints, for a full fledged
implementation I need to consider more corner cases. Therefore, I would
like to spend some more time on this before I push this new feature.
In total no huge changes. Still ok for mainline?
Although the v4 patches have been acked I'm not sure whether this falls
under the "is obvious" rule since I changed a little bit. If I get your
final Ok I will push these patches and will not bother you further ;-)
I already have an idea for the fourth patch (-fdemote-register-asm)
which I exclude for the moment and will come back to in the future.
It's often left to the submitter to decide if minor adjustments require
another review round. There's no firm policy.
A fairly easy line to draw is are you just adjusting to ongoing trunk
changes? If so, that's almost always not a problem and wouldn't suggest
a re-review.
If you made substantial changes to the implementation, then a re-review
is probably advisable.
For the stuff in the middle? Your best judgment as an engineer ;-)
Certainly if you post for a re-review, give us some idea of what changed
so we know where to focus.
Cheers,
Jeff
