TBAA bug?

2021-07-25 Thread Uecker, Martin 


Hi Richard,

here is another case where it seems that TBAA goes
wrong. Since this is not in a loop, it seems this
is something else than what we discussed. Is
this a known issue?

Best,
Martin


#include 
#include 

union u {
  long x;
  long long y;
};

__attribute__((noinline,noclone))
long test(long *px, long long *py, union u *pu)
{
  *px = 0;
  *py = 1;

  long xy = pu->y;
  pu->x = xy;

  return *px;
}

int main(void)
{
  union u u;
  printf("%ld\n", test(&u.x, &u.y, &u));
}

https://godbolt.org/z/a9drezEza

Re: An asm constraint issue (ARM FPU)

2021-07-25 Thread Marc Glisse 

On Sun, 25 Jul 2021, Zoltán Kócsi wrote:


I try to write a one-liner inline function to create a double form
a 64-bit integer, not converting it to a double but the integer
containing the bit pattern for the double (type spoofing).

The compiler is arm-eabi-gcc 8.2.0.
The target is a Cortex-A9, with NEON.

According to the info page the assembler constraint "w" denotes an FPU
double register, d0 - d31.

The code is the following:

double spoof( uint64_t x )
{
double r;

  asm volatile
  (
" vmov.64 %[d],%Q[i],%R[i] \n"


Isn't it supposed to be %P[d] for a double?
(the documentation is very lacking...)


: [d] "=w" (r)
: [i] "q" (x)
  );

  return r;
}

The command line:

arm-eabi-gcc -O0 -c -mcpu=cortex-a9 -mfloat-abi=hard -mfpu=neon-vfpv4 \
test.c

It compiles and the generated object code is this:

 :
  0:   e52db004push{fp}; (str fp, [sp, #-4]!)
  4:   e28db000add fp, sp, #0
  8:   e24dd014sub sp, sp, #20
  c:   e14b01f4strdr0, [fp, #-20]  ; 0xffec
 10:   e14b21d4ldrdr2, [fp, #-20]  ; 0xffec
 14:   ec432b30vmovd16, r2, r3
 18:   ed4b0b03vstrd16, [fp, #-12]
 1c:   e14b20dcldrdr2, [fp, #-12]
 20:   ec432b30vmovd16, r2, r3
 24:   eeb00b60vmov.f64d0, d16
 28:   e28bd000add sp, fp, #0
 2c:   e49db004pop {fp}; (ldr fp, [sp], #4)
 30:   e12fff1ebx  lr

which is not really efficient, but works.

However, if I specify -O1, -O2 or -Os then the compilation fails
because assembler complains. This is the assembly the compiler
generated, (comments and irrelevant stuff removed):

spoof:
  vmov.64 s0,r0,r1
  bx lr

where the problem is that 's0' is a single-precision float register and
it should be 'd0' instead.

Either I'm seriously missing something, in which case I would be most
obliged if someone sent me to the right direction; or it is a compiler
or documentation bug.

Thanks,

Zoltan


--
Marc Glisse

Function attribute to indicate a likely (or unlikely) return value

2021-07-25 Thread Dominique Pellé via Gcc 
Hi

I read https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
but was left wondering: is there a way to annotate a function
to indicate that a return value is likely (or unlikely)?

For example, let's say we have this function:

  // Return OK (=0) in case of success (frequent case)
  // or an error code != 0 in case of failure (rare case).
  int do_something();

If it's unlikely to fail, I wish I could declare the function like
this (pseudo-code!):

  int do_something() __likely_return(OK);

So wherever it's used, the optimizer can optimize branch
prediction and the instruction cache.  In other words, lines
like this:

  if (do_something() == OK)

...  would implicitly be similar to:

  // LIKELY defined as __builtin_expect((x), 1).
  if (LIKELY(do_something() == OK))

The advantage of being able to annotate the declaration,
is that we only need to annotate once in the header, and
all uses of the function can benefit from the optimization
without polluting/modifying all code where the function
is called.

Another example: a function that would be unlikely to
return NULL could be declared as:

  void *foo() __unlikely_returns(NULL);

This last example would be a bit similar to the
__attribute__((malloc)) since I read about it in the doc:

> In addition, the GCC predicts that a function with
> the attribute returns non-null in most cases.

Of course __attribute__((malloc)) gives other guarantees
(return value cannot alias any other pointer) so it's not
equivalent.

Would attribute __likely_return() and  __unlikely_return()
make sense?

Is there already a way to achieve this which I missed in
the doc?

Regards
Dominique

gcc-12-20210725 is now available

2021-07-25 Thread GCC Administrator via Gcc 
Snapshot gcc-12-20210725 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20210725/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision b454c40956947938c9e274d75cef8a43171f3efa

You'll find:

 gcc-12-20210725.tar.xz   Complete GCC

  SHA256=9f15451e777cdb6da0c21bff5f0bb61593ad4cb48e994f0eb13462c8ca33d2ee
  SHA1=b6f99513d4930afe36c93f1c4294084d93e7417c

Diffs from 12-20210718 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
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.

Re: Function attribute to indicate a likely (or unlikely) return value

2021-07-25 Thread Gabriel Ravier via Gcc 

On 7/25/21 7:33 PM, Dominique Pellé via Gcc wrote:

Hi

I read https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
but was left wondering: is there a way to annotate a function
to indicate that a return value is likely (or unlikely)?

For example, let's say we have this function:

   // Return OK (=0) in case of success (frequent case)
   // or an error code != 0 in case of failure (rare case).
   int do_something();

If it's unlikely to fail, I wish I could declare the function like
this (pseudo-code!):

   int do_something() __likely_return(OK);

So wherever it's used, the optimizer can optimize branch
prediction and the instruction cache.  In other words, lines
like this:

   if (do_something() == OK)

...  would implicitly be similar to:

   // LIKELY defined as __builtin_expect((x), 1).
   if (LIKELY(do_something() == OK))

The advantage of being able to annotate the declaration,
is that we only need to annotate once in the header, and
all uses of the function can benefit from the optimization
without polluting/modifying all code where the function
is called.

Another example: a function that would be unlikely to
return NULL could be declared as:

   void *foo() __unlikely_returns(NULL);

This last example would be a bit similar to the
__attribute__((malloc)) since I read about it in the doc:


In addition, the GCC predicts that a function with
the attribute returns non-null in most cases.

Of course __attribute__((malloc)) gives other guarantees
(return value cannot alias any other pointer) so it's not
equivalent.

Would attribute __likely_return() and  __unlikely_return()
make sense?

Is there already a way to achieve this which I missed in
the doc?


I'd assume this can be accomplished with a simple inline wrapper.



Regards
Dominique