Re: Help with an ABI peculiarity
Iain Sandoe writes: >> On 10 Jan 2022, at 10:46, Richard Sandiford >> wrot>> An alternative might be to make promote_function_arg a “proper” >> ABI hook, taking a cumulative_args_t and a function_arg_info. >> Perhaps the return case should become a separate hook at the >> same time. >> >> That would probably require more extensive changes than just >> updating the call sites, and I haven't really checked how much >> work it would be, but hopefully it wouldn't be too bad. >> >> The new hook would still be called before function_arg, but that >> should no longer be a problem, since the new hook arguments would >> give the target the information it needs to decide whether the >> argument is passed in registers. > > Yeah, this was my next port of call (I have looked at it ~10 times and then > decided “not today, maybe there’s a simpler way”). BTW, finally catching up on old email, I see this is essentially also the approach that Maxim was taking with the TARGET_FUNCTION_ARG_BOUNDARY patches. What's the situation with those? Sorry for not responding to them earlier. Thanks, Richard
gcc-9-20220120 is now available
Snapshot gcc-9-20220120 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20220120/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 1833b56864beaeaaeee2bd2e8227da1fa6bc You'll find: gcc-9-20220120.tar.xzComplete GCC SHA256=5f538f400c13680577f5815982e7afdebdd659457f83c9d902731cead070dbe5 SHA1=e84fc692cfb33416fc18a2677ffd6285ca52f3aa Diffs from 9-20220113 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Add new ABIs '__strcmpeq', '__strncmpeq', '__wcscmpeq' and '__wcsncmpeq' to libc
Hi All,
This is a proposal for four new interfaces to be supported by libc.
This is essentially the same proposal as '__memcmpeq()':
https://sourceware.org/pipermail/libc-alpha/2021-September/131099.html
for the character string and wide-character string comparison
functions.
Interfaces
int __strcmpeq(const void * s1, const void * s2)
int __strncmpeq(const void * s1, const void * s2, size_t n)
int __wcscmpeq(const wchar_t * ws1, const wchar_t * ws2)
int __wcsncmpeq(const wchar_t * ws1, const wchar_t * ws2, size_t n)
Descriptions
- 'strcmpeq()'
- The '__strcmpeq()' function shall compare the string pointed to
by 's1' to the string pointed to by 's2'. If the two strings are
equal the return value will be zero. Otherwise the return value
will be some non-zero value. 'strcmp()' is a valid
implementation of '__strcmpeq()'.
- 'strncmpeq()'
- The '__strncmpeq()' function shall compare not more than 'n'
bytes (bytes that follow a null byte are not compared) from the
array pointed to by 's1' to the array pointed to by 's2'. If the
two strings or first 'n' characters are equal the return value
will be zero. Otherwise the return value will be some non-zero
value. 'strncmp()' is a valid implementation of '__strncmpeq()'.
- 'wcscmpeq()'
- The '__wcscmpeq()' function shall compare the wide-character
string pointed to by 'ws1' to the wide-character string pointed
to by 'ws2'. If the two wide-character strings are equal the
return value will be zero. Otherwise the return value will be
some non-zero value. 'wcscmp()' is a valid implementation of
'__wcscmpeq()'.
- 'wcsncmpeq()'
- The '__wcsncmpeq()' function shall compare not more than 'n'
wide-character codes (wide-character codes that follow a null
wide-character code are not compared) from the array pointed to
by 'ws1' to the array pointed to by 'ws2'. If the two
wide-character strings or first 'n' characters are equal the
return value will be zero. Otherwise the return value will be
some non-zero value. 'wcsncmp()' is a valid implementation of
'__wcsncmpeq()'.
Use Case
The goal is that the new interfaces will be usable as an optimization
by compilers if a program uses the return value of the non "eq"
variant as a boolean. For example:
void
foo (const char *s1, const char *s2, const wchar_t *ws1, const wchar_t *ws2,
size_t n)
{
if (!strcmp (s1, s2))
printf ("strcmp can be optimized to __strcmpeq in this use case\n");
if (strncmp (s1, s2, n))
printf ("strncmp can be optimized to __strncmpeq in this use case\n");
if (wcscmp (ws1, ws2))
printf ("wcscmp can be optimized to __wcscmpeq in this use case\n");
if (!wcsncmp (ws1, ws2, n))
printf ("wcsncmp can be optimized to __wcsncmpeq in this use case\n");
}
Argument Specifications
- '__strcmpeq()' has the exact same argument specifications as 'strcmp()'
- 's1' is a null terminated character string.
- 's2' is a null terminated character string.
- '__strncmpeq()' has the exact same argument specifications as 'strncmp()'
- 's1' is a character sequences terminated either by null or 'n'
- 's2' is a character sequences terminated either by null or 'n'
- 'n' is the maximum number
- '__wcscmpeq()' has the exact same argument specifications as 'wcscmp()'
- 'ws1' is a null terminated wide-character string.
- 'ws2' is a null terminated wide-character string.
- '__wcsncmpeq()' has the exact same argument specifications as 'wcsncmp()'
- 'ws1' is a wide-character sequences terminated either by null or 'n'
- 'ws2' is a wide-character sequences terminated either by null or 'n'
- 'n' is the maximum number
For each of these functions, if any of the input constraints are not
met, the result is undefined.
Return Value Specification
- '__strcmpeq()'
- if 's1' and 's2' are equal, the return value is zero. Otherwise
the return value is any non-zero value. 'strcmp()',
'!!strcmp()', or '-strcmp()' are all valid implementations of
'__strcmpeq()'.
- '__strncmpeq()'
- if 's1' and 's2' are equal up to the first 'n' characters or up
to and including the first null character, the return value is
zero. Otherwise the return value is any non-zero
value. 'strncmp()', '!!strncmp()', or '-strncmp()' are all valid
implementations of '__strncmpeq()'.
- '__wcscmpeq()'
- if 'ws1' and 'ws2' are equal, the return value is
zero. Otherwise the return value is any non-zero
value. 'wcscmp()', '!!wcscmp()', or '-wcscmp()' are all valid
implementations of '__wcscmpeq()'.
- '__wcsncmpeq()'
- if 'ws1' and 'ws2' are equal up to the first 'n' wide-characters
or up to and including the first null wide-character, the return
value is zero. Otherwise the return value is any non-zero
value. 'wcsncmp()', '!!wc
Re: How to generate a call inst. sequence?
On Wed, 2022-01-19 at 10:45 +, Richard Sandiford wrote: > Andras Tantos writes: > > All, > > > > I'm working on porting GCC to a processor architecture that doesn't > > have > > a (HW) stack nor a call instruction. This means that for calls, I > > need > > to generate the following instruction sequence: > > > > // move stack-pointer: > > $sp <- $sp-4 > > // load return address: > > $r3 <- return_label > > // store return address on stack: > > mem[$sp] <- $r3 > > // jump to callee: > > $pc <- > > Even though this is internally a jump, it still needs to be > represented > as a (call …) rtx in rtl, and emitted using emit_call_insn. > > In other words, the "call" expander must always emit a call_insn > of some kind. (But it can emit other instructions too, such as the > ones you describe above.) > > Richard > Richard, Thanks for the reply. While what you're saying makes sense, it didn't solve my problems. The symptoms changed, but didn't completely go away. At the same time, I realized that - in this architecture - link- register-style calls are more efficient anyway, so I've changed my call implementation to that configuration. That got rid of the need for sloving this particular problem. So, just to document for people who might be looking at this thread in the future: this wasn't the complete answer to my problem, but I took a different route which removed the whole problem class. Thanks again, Andras
[PATCH] testsuite: avoid analyzer asm failures on non-Linux
On Sun, 2022-01-16 at 12:11 +0100, FX wrote:
> > No, that's "dg-do compile" (as in "compile but don't assemble").
>
> I can confirm that this patch:
>
> diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
> b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
> index c235e22fd01..4730255bb3c 100644
> --- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
> +++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
> @@ -1,4 +1,4 @@
> -/* { dg-do assemble { target x86_64-*-* } } */
> +/* { dg-do compile { target x86_64-*-* } } */
> /* { dg-require-effective-target lp64 } */
>
> #include "analyzer-decls.h”
>
>
> fixes the gcc.dg/analyzer/asm-x86-lp64-1.c failure on
> x86_64-apple-darwin. The same is true of this one:
>
> diff --git
> a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
> b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
> index e90dccf58dd..4cbf43206dc 100644
> ---
> a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
> +++
> b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
> @@ -1,4 +1,4 @@
> -/* { dg-do assemble { target x86_64-*-* } } */
> +/* { dg-do compile { target x86_64-*-* } } */
> /* { dg-require-effective-target lp64 } */
> /* { dg-additional-options "-fsanitize=bounds
> -fno-analyzer-call-summaries" } */
> /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
>
>
>
> These other three:
> FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c
> FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c
> FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c
>
> still fail with dg-do compile, as explained, become the error comes
> from the C front-end, not the assembler:
>
> /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
> warning: 'asm' operand 6 probably does not match constraints
> /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
> error: impossible constraint in 'asm'
Thanks. I extended your patch as follows, which works successfully for
me on x86_64-pc-linux-gnu.
Does the following look OK for the analyzer asm failures on
x86_64-apple-darwin?
Dave
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/asm-x86-1.c: Use dg-do "compile" rather than
"assemble".
* gcc.dg/analyzer/asm-x86-lp64-1.c: Likewise.
* gcc.dg/analyzer/asm-x86-lp64-2.c: Likewise.
* gcc.dg/analyzer/torture/asm-x86-linux-array_index_mask_nospec.c:
Likewise.
* gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:
Likewise, and restrict to x86_64-pc-linux-gnu.
* gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c: Likewise.
* gcc.dg/analyzer/torture/asm-x86-linux-cpuid.c: Use dg-do
"compile" rather than "assemble".
* gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c:
Likewise, and restrict to x86_64-pc-linux-gnu.
* gcc.dg/analyzer/torture/asm-x86-linux-rdmsr.c: Use dg-do
"compile" rather than "assemble".
* gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c:
Likewise.
* gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-reduced.c:
Likewise.
Signed-off-by: David Malcolm
---
gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c | 2 +-
gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c | 2 +-
gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-2.c | 2 +-
.../analyzer/torture/asm-x86-linux-array_index_mask_nospec.c| 2 +-
.../gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c| 2 +-
.../gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c| 2 +-
gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid.c | 2 +-
.../gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c | 2 +-
gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr.c | 2 +-
.../analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c| 2 +-
.../analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-reduced.c | 2 +-
11 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c
b/gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c
index f6026b7e288..a3f86e440b5 100644
--- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble { target x86_64-*-* } } */
+/* { dg-do compile { target x86_64-*-* } } */
#include "analyzer-decls.h"
diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
index c235e22fd01..4730255bb3c 100644
--- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble { target x86_64-*-* } } */
+/* { dg-do compile { target x86_64-*-* } } */
/* { dg-require-effective-target lp64 } */
#include "analyzer-decls.h"
diff -
